Dr. Doug Fridsma, Acting Director, ONC Office of Interoperability and Standards presented the ONC Standards and Interoperability Framework to the HIT Standards Federal Advisory Committee in today's meeting. A copy of the presentation he gave appears below:
Below is the raw transcript of Doug's presentation [I've just identified the speakers as best as I was able, there are NO other edits].
Doug Fridsma: Thank you very much. What I want to do is set the context, some of these we have said before but I want to make sure we frame the discussions that we have and I will provide the update of the other contacting issues that were we are at this point. The first thing is, part of the motivation for this work, is that there has been a lot of previous standards efforts and Jonathan Meyer was some of the ones that come out of his office as well but it is important to recognize that standards are nothing that we impose but they are best when they are adopted. So, to improve the adoption, we have to solve real problems. We need to be able to engage the community so they have a sense of ownership and I think one of the initiatives we have with the direct project is really an example of how getting people together that want to solve real problems and engage in a community helps us drive forward the adoption and usage of standards. Standards should be harmonized based on priorities and so we need to have some light to coordinate and prioritize the work we have been certainly, in the past there have been mechanisms in place and we, right now have the HIT policy and standard committee to provide recommendations pursuing. And we need to make sure that we have tools that will accelerate the adoption and vocabulary, I know Jamie Ferguson is working on a series at hearing that will happen later this week to address the issue of vocabulary and how best to do that and it is important that we have very easy to use implementation guides we have tools that can help with these options and implementations specifications are easy to use, easy to understand and difficult to misinterpret in terms of how they go forward. We have to make sure we keep things simple. If we are going to be solving problems, we need to make sure we don't boil the ocean for solve real focus problems and be able to use that as a beginning point that we can build out as we move forward. And that perfection is the enemy of good because we need to iterate and improve and have a mechanism that allows us to have that sort of work. So, as we look at some of the work that has been done in the past and we look at the tasks that are on our plate, going forward, one of the things I think is important is as we have continued emphasis on standardization's, we need to get to the point where we have increasingly computational implementation specifications and what I mean by that, we need to be able to have a mechanism that we have implementation specifications that can be manipulated with tools. We have data specifications are vocabulary resources that are stored in repositories that can then be used by people interested in information exchange. Rather than having a set of descriptions, perhaps, to be difficult to harmonize their grasp, it is important for meaningful use that we link standards from inception, from the problem we are trying to solve all the way through certification of any to be able to make sure that we have implementation specifications and standards that can be tested for certification and that means involving this and others early in the process and it is critical that whatever process we choose, and integration of multiple STO with different expertise across the process and that includes transportation practices, vocabulary and value sets in the integration of security into a more comprehensive framework. So what I hope people understand is that the standards interoperability and framework is the mechanism by which ONC will manage implementation specifications and hopefully, assist in the harmonization of existing IT standards to promote interoperability and meaningful use. So it is important to understand that the framework is not intended to develop new standards, although we have to work very closely with dinner development organizations do we identify a gap but will it be able to work with organizations throughout the healthcare domain and in a sense, come up with a shared understanding of what the requirements are for interoperability and the document and in these computational ways so that we can view them in a new process to help us better support the implementation specifications.
We hope this will give us a bunch of benefits. I hope it will help us manage the lifecycle because standards are not something that you simply declare our implementation specifications are something you declare, you'd actually be able to go and refine them as new technology comes out or as new kinds of exchanges are necessary. There is also some help that we will be able to reuse the standards that we have across multiple use cases. You know all start with a blank sheet of paper better able to reuse data element specifications that have been developed for a one use case in a use case for another purpose.
We need to develop semantic discipline so they work product is developed in a way that ensures the maximum computability and traceability in the lifecycle. It could be that, we have an understanding for exchange between not have a degree of semantics computability, if you will, or standardization and in terms of managing that lifecycle, we need to make sure we have the ability to go from things that are less a specified in things that are more specified, the graceful degradation although I think they had a different term and we need to be able to have more products that can migrate to that lifecycle and ultimately, human consensus is the first step to achieving computer consensus are interoperability and we do have that process in place. One of the things that we have a working on for the last few months is trying to come up with a framework that will help to support this. And there has been some delay in getting the contracting process out there and getting all of our contracts awarded. But at this point, we are within a couple of weeks of having all of our contracts out there and so I think it is time for us to be able to identify who are the people that are going to be doing this and how this is intended to help support the work of implementation specification and standards.
So, this is a description or a picture of the standards and interoperability framework. If you take a look, you can see development of functional requirements contract is in the final stages of review at this point and we hope to be able to make an announcement within the next week or so when I was exchanging information this morning around the particular award. Harmonization of -- which is a new framework and implementation specification has been awarded two -- if you think about the case development is being outward looking and trying to develop a community of users that would come to the table with functional requirements and the like, for a particular problem to solve, the team will be more inward looking and a sense that they will assist those teams and trying to translate those cases and functional requirements into a standardized way of looking at things with them the main framework. So, they will hopefully develop implementation specifications based on the -- and augmented by some of the needs that we have to describe services and not just data elements. There is another group that has gotten to the contracts, the first being reference implementation and the second being pilot demonstration projects. Those two contracts went to Lockheed Martin. The goal of the reference implementation is to make sure we have our implementation specifications right and they will serve in the role of testing the implementation specifications and making sure that we are not missing anything but beer implementation specification can actually and helping us with pilots doubled past the implementation specifications in the real world and wall looking at new ones, that may be needed to go out there. There is another group certification and testing, and we lump those together there'll be certification that is currently under review and there is a testing tool that was awarded to Staley. Stanley received the testing contractor as well as the tools services to support interoperability framework amounts of support operational features and operational functions of the NHI in as well. There is one that we are the process of rewriting the RFP and that is standard development contract. The goal there was to provide focused work when we had identified a particular standard that needed to be brought to a STO or creation of value sets or other things that might help us with the standards development and that particular contract, we have elected to repeat. There will be a delay in getting out on out there but we hope we can do that expeditiously. We are certain there is a lot of work that needs to be done. To try to bring all these pieces together. With each of these awards, has been critical for the participants that we do not start with a blank sheet of paper. And that we leverage all the work that has been done in the past.
For example, when it comes to the harmonization and implementation specification work, we have to leverage the work that has been done in the past, particular way as it relates to meaningful use. The work on non-with the records implementation, you can leverage some of the work that is going on with connect and FHA. And certainly, the certification and testing team needs to extend the work that we have with the missed tools and make sure that we can put those together in a testing environment that will allow people to use the reference implementation and make sure that is working for them and string together some of the conformance test into business scenarios where you send that they think it's an acknowledgment back and resend them if there needs to be updates.
Throughout this, we have a whole series of contracts that are currently getting started. Most of them have been awarded within the last three weeks. And we have not, have plans that in the middle of September, we will have everybody come together and launch how we expect people to work together to make this happen. I think the thing that we are trying to achieve and this is the, a trade-off that we have between command and control, top-down development standards and limitations the citations are letting lots of people do whatever they want and hope that there are 1000 flowers that brought gloomily get picked the previous ones that are there. I think what we are trying to do is get the focus of collaboration and a good example of where we are going with this is that we have had tremendous engagement in the community around the direct projects but if you pair that in with the interoperability framework, we hope that will help us up from the bottom up, develop the kinds of standards and implementation specifications that we have both in a larger framework that will help coordinate that Matt is going to require for us to develop prioritization, transparency, engagement of the community and trying to iterate rapidly as we develop standards and implementations specifications.
In large part, what we are trying to achieve with this is that to have the standards and interoperability framework essentially develop all the implementation specifications or standards in a vacuum but to have that serve as a platform that will support the work of a larger community. And provide a way for collaboration to occur across a broad set of stakeholders and if we think about that, the direct project was developed using rapid iteration, develop a working implementation and lots of feedback from the real world. We need to leverage that kind of work to make sure that that fits into the larger framework that as we have multiple kinds of cases out there animal to pull groups that are working on a kind of engagement, that we have the ability to get all of those people to collaborate together in a focused way, I ran the priorities that we have and around me work that we have going forward. So, in large part, we need to be able to leverage the HIT community and take professional organizations, government agencies, standard development organizations as well and make sure all the work that is going on with regard to developing specific solutions to cases, all come down to a harmonized set of standards and implement the specifications that can be integrated across the work that we have. There is a whole series of different, there is another way we can look at this as well, always think about the very specific kinds of standards that need to be constructed. We need to think about transportation standards and certainly the direct project has looked at the kind of communication protocols between systems. We have to make sure we develop a concent -- content exchange standards, those adopted for clinical summaries, prescriptions, electronic documents and make sure we have standardized nomenclature, value sets the help support vocabulary and we certainly hope to get additional feedback later this week from the vocabulary hearings that are going on.
Throughout this, we need to make sure we have privacy and security that all fit together to support the implementation specifications that we have. It is going to be a challenge, clearly, as we go forward and I think we have to, as we think about this, develop some strategies and get feedback fromthe people that are on the HIT standards committee and in the various work groups.
We have a lot of different health information exchange, standard, specifications and application standards and we hope that we can begin to solve real problems around the meaningful use and make sure that we identify from that the exchange requirements that exist, identifying gaps, duplications, or were labs that were to develop a core set of standards and specifications that will help support meaningful use.
There are issues around usability of existing HIT standards and specifications and I have been very clear with the groups as they have started to think about their approaches and various contracts and the complexity will be our enemy and that to whatever degree we can simplify the work that we have and have very clear implementation specifications, perhaps even implementation specifications that can be into software development tools that are out there, I think we'll have much better successes and getting the standards adopted and used in ways that will emanate or reduce, maybe not eliminate that reduce the ambiguity that we have with some of the specifications. We know already, many of the things that we will require for healthcare, exceed the existing processes tools and artifacts that we have been working closely and extending the need processes to include not only specifications of data but also to include specifications around the services that need to be described and behavioral aspects of standards as well. And so, we are currently working on taking the high APD and extended a way as to include some of those kinds of behavioral and service descriptions as well. It is going to be clear that we have to harmonize the vocabulary and value sets and gets a level of specificity and so leveraging existing vocabulary were repositories and collaborating with standard development organizations and people that have expertise in managing vocabulary of value sets will be critical. But we have to make sure we have the ability to support the balance and effective participation of the HIT stakeholders.
Bennies to being gauge meant at all levels as we go forward so that we have the kind of expertise to support this work. There is probably three levels alleged that coordination has to occur. At a strategic level, we have to make that we are aligned towards achieving specific goals and I think certainly within the setting of meaningful use we have clear goals there but also, we have several partners and groups that may or may not be specifically , whose purview may be larger than meaningful use and we need to make sure that as some of those people get ahead of the curve and I started to work on things that are more forward thinking, that we think strategically about how all of us can converge and establish those goals. We have some operational coordination so we can effectively prioritize and manage our work so that, although we hope to make available as many tools and resources that people can be self-sufficient was, clearly, we have more work that needs to be done than resources to support that and so, effectively prioritize a managing network and getting broad input all work is going to be critical.
We have technical issues. We have to make choices in terms of how we will represent information and how we will manage and version and coordinate around the models and standards that are being promulgated and that is also going to be an area that will be necessary. What we really want to be able to do is have a top down approach that helps us with goals and recognizes things that are accepted as implementation specification but we want to make sure that we drive this bottle of holy establish cooperation and involvement of the standards community and various age IT stakeholders in the process. And so, in some sense the framework is really a platform for collaboration around standards but focused on helping us solve real problems in this bottom-up way. Although the contractors will help us establish some of that infrastructure and help us manage that operation, it is to be effective, the whole standards and interoperability framework need to have coronation with the community and participation so we do the right thing. So if the framework is to be successful, it needs to have sustainable, it repeatable sets of operations. That echo what we talked about, principles. We need to establish problem oriented approaches to defining, prior to Isaac, and executing activity way to develop and adopt processes that ensure collaboration and transparency of Anita identify areas that facilitate stakeholder engagement and provide infrastructure that will get us to the goal with rapid results. So, I want to end with this last slide which is, this is really what we are trying to achieve in a standard interoperability framework, trying to figure out how they can make sure that government, as a platform, can support the work of organizations and stakeholders like direct to come up with problems they want to solve and that we can provide a framework that helps collaborate around her organization, transparency, engagement, and rapid results so we can reuse the standards that are out there, that we can maintain consistency across the standards that are developed a way to make sure they fit into the needs that we have within the meaningful use words to make sure that we can drive us towards certification criteria as well. So with that, I am going to turn it back over to you, John, and see if there are questions or comments about what it is we are trying to do.
John Halamka: Thank you very much. I think all of us are very interested in providing coordination, oversight, and coronation to help you in this activity and it would seem that one of our collective risks is the application of a framework in the past has been Department of Homeland Security, Department of Justice, may have been there were less existent standards, less existent interfaces, maybe there were, a greater sense of urgency so it would be fascinating to see if you could take a framework that has worked successfully in government, which has slightly different environments, slightly different complexity slather different data models and wrapped into healthcare. I think all of your principles are very good but will it erase that as a risk in any, that you have on that risk.
Doug Fridsma: I think, you raise an important risk that is there. Indeed, in our experience that we have had with some of the early work, and looking at -- 32 and the like, we recognize there is perhaps more complexity than some of the problems we are trying to solve within healthcare than there are in some of the other kinds of data exchanges that are out there. I think we will have to be vigilant about that. I think part of what I have tried to emphasize is the process that we go through to come up with to the specifications is not that dissimilar to the kinds of processes we have within other standard organizations and certainly, those that have been used within -- some of the work that has gone on with HL seven and other organizations like MCI. You have a subtly nuanced differences some of them have different approaches to tackling those programs that I think there is consistency that there are certain things that you have to do and I am hopeful that the process will give us a framework to do that. And allow it to take the best from all of the different organizations and all of the different processes and incorporate them into a collaborative framework.
John Halamka: Thank you and let me open it up. I'm sure there are many questions.
Stan Huff: Does this stand. I like the overall approach and the collaborative nature and I guess where I have some confusion , I don't have a clear picture, maybe it's a better way to say it, is how, the interoperability framework interacting with the formal processes in the other standards development organizations and in particular, I'm thinking, if you needed a standard, to an extent, you may be able to rapidly make a new prototype or propose a new standard, does not need to go to ballot somewhere? Can you use the existing standard organizations balloting process or does ONC actually envision becoming a goober standard development organization where there would be a formal way of balloting those things within -- itself so I like the approach that I can see see the details of how those interactions are going to incur how you envision that.
Doug Fridsma: I think, the goal is to help ordinate across all of the different standard development organizations. I don't see this as being a goober standard organization in which there might be balloting all our this is going to replace the work of the STL. I think one of the things that is clear and we have seen us and many of the requirements that we have for meaningful use and the activities of healthcare reform is oftentimes we are faced with a possible try France to come up with a recommended set of standards for publication specifications or the like. It is useful to be able to have organizations that can come up with a potential standard or a potential way of exchanging information, very simple -- very similar to -- all those pieces that come together, what is going to be the transfer? What is going to be the content? What are going to be the values that the terminology then, you have the package and you can work with the -- to make sure those things can be ballot is an inappropriate way. That is what the vision would be. I think we are cognizant of the circular, a one a 119 the president of the framework, the government doesn't have the job of creating standards but rather identifying the need for standards and working with the SCO to make sure we have that. Much of this, framework, as an effort to create a common way of representing what those requirements will be, what the problems are we are trying to solve a created as a publication specifications that will be based around existing and perhaps standards that yet need to be. It and working with the FDA to make sure they get ballots appropriately.
Was questions?
Wes Rishel: This is less. -- Wes. I will try to disguise these, those questions. We really have a fuzzy set of distinctions between standards development organizations and profile her and force her organizations. Maybe a better way to say would be there is a continuum between standards, developers, profilers, and enforcers, three different kinds of organizations. And if we look at the current direct operation, for example, is more of a profiler. It didn't really define standards, decided how to pick among standards and create interfaces between the different kinds of standards. They arguably, IAG is a profiler. And -- as a profiler. And, the road was icy, one of the pluses of food Co. recruits although the big problems profile organizations have had, not being able to create a coherent publication they can only do that if it requires the right to intellectual property as part of the contract that you are working on. It has to have the ability crew to create works on its own. If you have the spectrum from SCO to profiler to certify her, you have a triangle pointing the other way about the links of time it takes for work that is started their to become actually practical as a means for health information exchange and that is where, as you pointed out, we have a tremendous amount of time pressure on making decisions, recognizing that from the start of an idea, for a new standard, to be practical for large scale implementation, unless it is a trivial topic, we're talking about a minimum of five years. So I think there needs to be some sort of visioning process as well that is looking downstream for standards that we will need when there is time to use the benefits of a consensus process to get a broad take out what the requirements are to what the possible solutions are.
Any comments?
Doug Fridsma: No, I like the distinction is made between profiler and enforcer. And I think trying to meet our legislative requirements with standard development and be able to support meaningful use, and be able to balance that with making sure we have engagement from all various participants is one of the motivations and reasons why we are trying to get something together in the interoperability framework. I will say, one thing that is a non-resolve the issue and this may be something that this committee can provide some input on, is the issue that was raised about intellectual property and engaging with the standards development organization. Clearly, that is a implementation in terms of how we work together with this. And that solving problems requires multiple groups to be able to come together and bring expertise to the table so that we have a comprehensive package that is useful to the implementers and the people trying to meet meaningful use, I think it will be important for us to get an array of engaging the FDA on making sure that we get a comprehensive policy, perhaps engage the STL is that they can contribute to those packages still be able to have business models that are available to support the work they do.
Wes Rishel: If I can repeat a rule of standards. When you change the consensus group, you change the consensus. And we have all of these issues about , if you take something that was developed violent group and ask a -- to endorse it, and the endorsement is meaningful, loss of change the standard. So you somehow need to create a collaboration process that the standards, the -- are obligated to effectively put up or shut up and say, we as they STL endorse this and it becomes an act of the STL are the SCO does not play. It is going to take some sort of active leadership here to get beyond I talk about difficulties that we had, not out at disrespect for the people who struggled hard to the do them but nonetheless, because of the struggles that they had.
To put commas, you have included the -- in the framework and the processor that is actually going to be a -- you're going to compete with some coordination there. One of the things I concur with what you said, it is important to think about the intellectual property issue because one of the reason people are confused by the version 2.5 implementation guide included -- was because that inclusion was actually through, interaction, see 83 which was referenced in C. 32 because of the fact that we cannot license all of this wind up with artifacts project artifacts pointing to artifacts that would be wonderful to have crisp, clear, artifacts and light and commercial properties for general use.
Of the commons?
Nancy Orvus: This Nancy John, I am glad you so but that was because that is the underlying issue, the business model and the financing of the continuing to standards and whatever. And I think also nine that as I said, one of the issues, federal, state, or local entities, they generally get a pass or endorsement from their government entity to participate because consensus-based standards are generally not as partisan are not exactly what they say, consensus-based but yes, we should definitely address the business financing model of intellectual property and development of -- and I would just say, also for those who are trying to help, as an organizational providers, or government agencies, it can be, or will become a bit fuel during on where to, all the various levels to the side truce truce was to provide input for, here are the projects or to supply bodies or ask for funding. We are looking very much forward to the next stage of this because it will certainly help us get a context in which to do the work that we all need to do.
The document will help a lot with that and Doug's intent is to circulate it to us when they get to a stage where it is more polished and therefore, we will have input into how all of this interacts and how we interact with it.
For those of us who have worked on integration, we love complexity,
But we definitely need some help, always communicating through leadership and decision makers.
Other comments on Doug's presentation?
Carol Diamond: This is Carol. I made this point many times in the past but I'm going to make it again and suggest that it is time to operationalize it. Many times I attacked on the interplay between policy and technology and why of a formation of standards, implementation and policy needs to be there in a visible and required way. My sense is that because they may process -- progress of the Tiger team recommendation exchange in the ONC framework is in place, those policy requirements need to actually get to be a part of the way you are contracting for some of this work to be done. In other words, it is okay to say privacy and security is an element we are working on but I think it really needs to be integrated into the approach of framework, and a very operational way and I think it is timely to start thinking about ways to do that. Interoperability and harmonization also apply to policy and out hate to see us get into a situation where the technology standards are the use cases are the implementation guide has to reworked or the policy objectives can be fulfilled because it's had core requirements were developed other things and I think that akin to parser work into policy and technology but from my perspective, listening to this today, and no a contractor out, it is the moment to start integrated news and a operational way.
The second point I want to make, just as you said, this is a platform for collaboration and innovation and I would argue it should be a platform for innovation and collaboration on some of the policy objectives that need to be fulfilled by technology so the Tiger team, needs recommendations on granular technology for consent and other things that really could be incorporated into this framework as a way to examine the policy objectives as well using technology and I would hate to see this silo that these are viewed as two separate areas or to separate strands of work and not brought together in a robust and meaningful way.
I think you are right that we should have a close coordination with policy and technology and let me give you a example of one of the challenges that I have and I think one of the things that we are trying to achieve on the technology side, there were may require us to make sure that we don't have a -- between policy and technology. Her go to the standards and interoperability framework is to have the ability to have data and service descriptions be reusable across multiple use cases. We have a granularity of the data elements that we described in a granularity in the services and we simply, which I take those things and create building blocks that -- it is important that policy work also thinks about things in modular driven approaches within a larger framework. I know that there has been work within the exchange to develop -- which is at large was a party agreement and that agreement, we have policies that are one-size-fits-all way to standards and services that are meant to be modular and are used, we start to get into the impedance mismatch between policy and technology and we have trouble doing exactly what you said, which is to make sure there is a close coronation within a --
I don't think the policy right now does in the way of a modular approach. In fact, the class form that you have for collaboration is a wonderful place to have it tested but I wanted to be clear about what I am urging you to do, which is to not say the technology and policy needs to be cored native but rather to say these are the policies of the technology and the standards and implementation guides, these are the policies they have to fulfill. I worry, if you don't do that, the policy work is an academic exercise and best case, worst case, it gets at the technical approach getting brief thought in the context of the policy down the road, which is also not an ideal outcome. I agree this interplay that is in both directions but that would be clear that because of the that the rating -- the policy committee and the Tiger team on another front, this is the moment because the Tiger team focused on stage one meaningful use of information exchange it because you are doing these contracts now for, to develop specifications and a technical model, has to be informed by at least a basic rubric and the other thing I will say, if you look at the platform for innovation on the technical front, you should look at a technical platform I policy up front and the kinds of problems and challenges that you mentioned, technically, can also be solved from a policy perspective from bringing the challenges to the same innovation platform and finding ways to solve them as opposed to two streams at different paces and every now and then there is the chicken and some will say this all work we're doing but the real number here is to be developed as a public policy perspective, has to be incorporated into the contractual and ONC sponsored approach or I worry that it may not come together.
Doug Fridsma: Valuable input. The policies would be integrated in the back to the comment the very least and hopefully multiple other checkpoints in the process.
We define a nationwide health information network as the data standard services and policies to support information exchange and so we need to figure out a way to make sure that happens and I think you are right, will likely happen at the beginning of the process through the cases and I think there is, we need to make sure we are vigilant about that.
Any other closing comments before we move on?
David McCallie: This is David. I have one question for Doug. Doug, one of the contracts was for reference implementation I'm curious, is an implementation of what? Of the tools are actual exchange services? Or some combination?
It is meant to be of the specifications that come out of the standards and interoperability framework. Again keep you a concrete example that is, the nationwide health information network as a series of specifications that describe the data services for using -- to provide that kind of exchange. We have FHA can act, which is a tool that, a piece of software that many people use it to help support exchanges in NHI and specifications that connecting, and another son, has made particular choices when it comes to option Audi and specifications. That means that there is although can act as agents of the specification, it may or may not be a, considered a reference implementation because they have chosen to, for example, implementing synchronous communications whereby the specifications talk about synchronous and asynchronous communication. The goal here is to have a one-to-one correspondence between specifications that we have for the nationwide information network ever meaningful use it to have a corresponding piece of software or code that actually implement that.
This sounds like an immense amount of software.
Doug Fridsma: I think, do it -- the rationality hope is that the reference implementation will be, will leverage much of the work that is being done in the past. They sure if it is read from consisting codes, those pieces that are part of that implementation. The goal is to not produce production level code the people could necessarily download directly but to make sure that we test our implementation specification and have gone through that particular exercise. Remember, we have open community that we have within the connects project and we are examining whether we can use similar mechanisms to help us with some of the work on rapid implementation following a model that has been successful at open sewers communities. Stewardesses Dixie Baker. I have a question. Have you established some of these questions that people brought up are really valid considerations. Have you established milestones and metrics for actually measuring and taking the process along the way?
That is one of the first charges of the various people that are working on the contract. Essentially, establish metrics, milestones interests to have the availability to track progress to this and trying to integrate a lot of that work into the ongoing operation within the coordinator and those things are part of the blue want to try to do with this work. Most of the contracts have been awarded within the last three weeks. There is lots of room for us to be able to take feedback and suggestions, recommendations, and include it in the work that is just beginning.
Metrics and milestones for the overall means progress were each of these processes?
It is both of those and obviously, the lower-level metrics, needs to fit into the overall goals we have for meaningful use. There needs to be a rolling up of metrics to make sure they are satisfying the overall objectives of the office.
David Tao of Siemens was able to ask a question at the end of the meeting about the projected availability of the CONOPS document.
Doug Fridsma: I think you are right, this will help us tie all of these pieces together. We have a document that we have been working on that we are beginning to circulate to see if there are pieces that are missing. We have been coordinating with some of the other organizations, particularly with some of the people from -- to see that we have a consistent view of the world and we also have a working with some of the people from HHS to have participated as well. I think there is wide to be something out of the next few weeks and I expect it will be at a level of detail that will be higher than most people are going to want and in part, before we walk down entirely, we will have some thoughtful public input to make sure we have coordination strategies right. That is one of the key parts of this and I think until we have all of our contract awarded, it is going to be difficult for us to have that it has finalized version.
My own question went unaddressed, which I'll attribute to technical issues [although I submitted via phone and web] and not to any editorializing by the FACA. It's basically this:
How will ONC ensure coordination and communication between these 11 different contracts without becoming a bottleneck. I remember back to a time in a previous administration where all communciation between HITSP, CCHIT, NHIN, HITSC and AHIC went through ONC, and the complete disaster that was for coordination. My hope is that the new ONC [with about 10 times the staff] will do better, but also will be neither a filter or a restrictor of communications. The answer may well be in the CONOPS document that David Tao referenced.
Below is the raw transcript of Doug's presentation [I've just identified the speakers as best as I was able, there are NO other edits].
Doug Fridsma: Thank you very much. What I want to do is set the context, some of these we have said before but I want to make sure we frame the discussions that we have and I will provide the update of the other contacting issues that were we are at this point. The first thing is, part of the motivation for this work, is that there has been a lot of previous standards efforts and Jonathan Meyer was some of the ones that come out of his office as well but it is important to recognize that standards are nothing that we impose but they are best when they are adopted. So, to improve the adoption, we have to solve real problems. We need to be able to engage the community so they have a sense of ownership and I think one of the initiatives we have with the direct project is really an example of how getting people together that want to solve real problems and engage in a community helps us drive forward the adoption and usage of standards. Standards should be harmonized based on priorities and so we need to have some light to coordinate and prioritize the work we have been certainly, in the past there have been mechanisms in place and we, right now have the HIT policy and standard committee to provide recommendations pursuing. And we need to make sure that we have tools that will accelerate the adoption and vocabulary, I know Jamie Ferguson is working on a series at hearing that will happen later this week to address the issue of vocabulary and how best to do that and it is important that we have very easy to use implementation guides we have tools that can help with these options and implementations specifications are easy to use, easy to understand and difficult to misinterpret in terms of how they go forward. We have to make sure we keep things simple. If we are going to be solving problems, we need to make sure we don't boil the ocean for solve real focus problems and be able to use that as a beginning point that we can build out as we move forward. And that perfection is the enemy of good because we need to iterate and improve and have a mechanism that allows us to have that sort of work. So, as we look at some of the work that has been done in the past and we look at the tasks that are on our plate, going forward, one of the things I think is important is as we have continued emphasis on standardization's, we need to get to the point where we have increasingly computational implementation specifications and what I mean by that, we need to be able to have a mechanism that we have implementation specifications that can be manipulated with tools. We have data specifications are vocabulary resources that are stored in repositories that can then be used by people interested in information exchange. Rather than having a set of descriptions, perhaps, to be difficult to harmonize their grasp, it is important for meaningful use that we link standards from inception, from the problem we are trying to solve all the way through certification of any to be able to make sure that we have implementation specifications and standards that can be tested for certification and that means involving this and others early in the process and it is critical that whatever process we choose, and integration of multiple STO with different expertise across the process and that includes transportation practices, vocabulary and value sets in the integration of security into a more comprehensive framework. So what I hope people understand is that the standards interoperability and framework is the mechanism by which ONC will manage implementation specifications and hopefully, assist in the harmonization of existing IT standards to promote interoperability and meaningful use. So it is important to understand that the framework is not intended to develop new standards, although we have to work very closely with dinner development organizations do we identify a gap but will it be able to work with organizations throughout the healthcare domain and in a sense, come up with a shared understanding of what the requirements are for interoperability and the document and in these computational ways so that we can view them in a new process to help us better support the implementation specifications.
We hope this will give us a bunch of benefits. I hope it will help us manage the lifecycle because standards are not something that you simply declare our implementation specifications are something you declare, you'd actually be able to go and refine them as new technology comes out or as new kinds of exchanges are necessary. There is also some help that we will be able to reuse the standards that we have across multiple use cases. You know all start with a blank sheet of paper better able to reuse data element specifications that have been developed for a one use case in a use case for another purpose.
We need to develop semantic discipline so they work product is developed in a way that ensures the maximum computability and traceability in the lifecycle. It could be that, we have an understanding for exchange between not have a degree of semantics computability, if you will, or standardization and in terms of managing that lifecycle, we need to make sure we have the ability to go from things that are less a specified in things that are more specified, the graceful degradation although I think they had a different term and we need to be able to have more products that can migrate to that lifecycle and ultimately, human consensus is the first step to achieving computer consensus are interoperability and we do have that process in place. One of the things that we have a working on for the last few months is trying to come up with a framework that will help to support this. And there has been some delay in getting the contracting process out there and getting all of our contracts awarded. But at this point, we are within a couple of weeks of having all of our contracts out there and so I think it is time for us to be able to identify who are the people that are going to be doing this and how this is intended to help support the work of implementation specification and standards.
So, this is a description or a picture of the standards and interoperability framework. If you take a look, you can see development of functional requirements contract is in the final stages of review at this point and we hope to be able to make an announcement within the next week or so when I was exchanging information this morning around the particular award. Harmonization of -- which is a new framework and implementation specification has been awarded two -- if you think about the case development is being outward looking and trying to develop a community of users that would come to the table with functional requirements and the like, for a particular problem to solve, the team will be more inward looking and a sense that they will assist those teams and trying to translate those cases and functional requirements into a standardized way of looking at things with them the main framework. So, they will hopefully develop implementation specifications based on the -- and augmented by some of the needs that we have to describe services and not just data elements. There is another group that has gotten to the contracts, the first being reference implementation and the second being pilot demonstration projects. Those two contracts went to Lockheed Martin. The goal of the reference implementation is to make sure we have our implementation specifications right and they will serve in the role of testing the implementation specifications and making sure that we are not missing anything but beer implementation specification can actually and helping us with pilots doubled past the implementation specifications in the real world and wall looking at new ones, that may be needed to go out there. There is another group certification and testing, and we lump those together there'll be certification that is currently under review and there is a testing tool that was awarded to Staley. Stanley received the testing contractor as well as the tools services to support interoperability framework amounts of support operational features and operational functions of the NHI in as well. There is one that we are the process of rewriting the RFP and that is standard development contract. The goal there was to provide focused work when we had identified a particular standard that needed to be brought to a STO or creation of value sets or other things that might help us with the standards development and that particular contract, we have elected to repeat. There will be a delay in getting out on out there but we hope we can do that expeditiously. We are certain there is a lot of work that needs to be done. To try to bring all these pieces together. With each of these awards, has been critical for the participants that we do not start with a blank sheet of paper. And that we leverage all the work that has been done in the past.
For example, when it comes to the harmonization and implementation specification work, we have to leverage the work that has been done in the past, particular way as it relates to meaningful use. The work on non-with the records implementation, you can leverage some of the work that is going on with connect and FHA. And certainly, the certification and testing team needs to extend the work that we have with the missed tools and make sure that we can put those together in a testing environment that will allow people to use the reference implementation and make sure that is working for them and string together some of the conformance test into business scenarios where you send that they think it's an acknowledgment back and resend them if there needs to be updates.
Throughout this, we have a whole series of contracts that are currently getting started. Most of them have been awarded within the last three weeks. And we have not, have plans that in the middle of September, we will have everybody come together and launch how we expect people to work together to make this happen. I think the thing that we are trying to achieve and this is the, a trade-off that we have between command and control, top-down development standards and limitations the citations are letting lots of people do whatever they want and hope that there are 1000 flowers that brought gloomily get picked the previous ones that are there. I think what we are trying to do is get the focus of collaboration and a good example of where we are going with this is that we have had tremendous engagement in the community around the direct projects but if you pair that in with the interoperability framework, we hope that will help us up from the bottom up, develop the kinds of standards and implementation specifications that we have both in a larger framework that will help coordinate that Matt is going to require for us to develop prioritization, transparency, engagement of the community and trying to iterate rapidly as we develop standards and implementations specifications.
In large part, what we are trying to achieve with this is that to have the standards and interoperability framework essentially develop all the implementation specifications or standards in a vacuum but to have that serve as a platform that will support the work of a larger community. And provide a way for collaboration to occur across a broad set of stakeholders and if we think about that, the direct project was developed using rapid iteration, develop a working implementation and lots of feedback from the real world. We need to leverage that kind of work to make sure that that fits into the larger framework that as we have multiple kinds of cases out there animal to pull groups that are working on a kind of engagement, that we have the ability to get all of those people to collaborate together in a focused way, I ran the priorities that we have and around me work that we have going forward. So, in large part, we need to be able to leverage the HIT community and take professional organizations, government agencies, standard development organizations as well and make sure all the work that is going on with regard to developing specific solutions to cases, all come down to a harmonized set of standards and implement the specifications that can be integrated across the work that we have. There is a whole series of different, there is another way we can look at this as well, always think about the very specific kinds of standards that need to be constructed. We need to think about transportation standards and certainly the direct project has looked at the kind of communication protocols between systems. We have to make sure we develop a concent -- content exchange standards, those adopted for clinical summaries, prescriptions, electronic documents and make sure we have standardized nomenclature, value sets the help support vocabulary and we certainly hope to get additional feedback later this week from the vocabulary hearings that are going on.
Throughout this, we need to make sure we have privacy and security that all fit together to support the implementation specifications that we have. It is going to be a challenge, clearly, as we go forward and I think we have to, as we think about this, develop some strategies and get feedback fromthe people that are on the HIT standards committee and in the various work groups.
We have a lot of different health information exchange, standard, specifications and application standards and we hope that we can begin to solve real problems around the meaningful use and make sure that we identify from that the exchange requirements that exist, identifying gaps, duplications, or were labs that were to develop a core set of standards and specifications that will help support meaningful use.
There are issues around usability of existing HIT standards and specifications and I have been very clear with the groups as they have started to think about their approaches and various contracts and the complexity will be our enemy and that to whatever degree we can simplify the work that we have and have very clear implementation specifications, perhaps even implementation specifications that can be into software development tools that are out there, I think we'll have much better successes and getting the standards adopted and used in ways that will emanate or reduce, maybe not eliminate that reduce the ambiguity that we have with some of the specifications. We know already, many of the things that we will require for healthcare, exceed the existing processes tools and artifacts that we have been working closely and extending the need processes to include not only specifications of data but also to include specifications around the services that need to be described and behavioral aspects of standards as well. And so, we are currently working on taking the high APD and extended a way as to include some of those kinds of behavioral and service descriptions as well. It is going to be clear that we have to harmonize the vocabulary and value sets and gets a level of specificity and so leveraging existing vocabulary were repositories and collaborating with standard development organizations and people that have expertise in managing vocabulary of value sets will be critical. But we have to make sure we have the ability to support the balance and effective participation of the HIT stakeholders.
Bennies to being gauge meant at all levels as we go forward so that we have the kind of expertise to support this work. There is probably three levels alleged that coordination has to occur. At a strategic level, we have to make that we are aligned towards achieving specific goals and I think certainly within the setting of meaningful use we have clear goals there but also, we have several partners and groups that may or may not be specifically , whose purview may be larger than meaningful use and we need to make sure that as some of those people get ahead of the curve and I started to work on things that are more forward thinking, that we think strategically about how all of us can converge and establish those goals. We have some operational coordination so we can effectively prioritize and manage our work so that, although we hope to make available as many tools and resources that people can be self-sufficient was, clearly, we have more work that needs to be done than resources to support that and so, effectively prioritize a managing network and getting broad input all work is going to be critical.
We have technical issues. We have to make choices in terms of how we will represent information and how we will manage and version and coordinate around the models and standards that are being promulgated and that is also going to be an area that will be necessary. What we really want to be able to do is have a top down approach that helps us with goals and recognizes things that are accepted as implementation specification but we want to make sure that we drive this bottle of holy establish cooperation and involvement of the standards community and various age IT stakeholders in the process. And so, in some sense the framework is really a platform for collaboration around standards but focused on helping us solve real problems in this bottom-up way. Although the contractors will help us establish some of that infrastructure and help us manage that operation, it is to be effective, the whole standards and interoperability framework need to have coronation with the community and participation so we do the right thing. So if the framework is to be successful, it needs to have sustainable, it repeatable sets of operations. That echo what we talked about, principles. We need to establish problem oriented approaches to defining, prior to Isaac, and executing activity way to develop and adopt processes that ensure collaboration and transparency of Anita identify areas that facilitate stakeholder engagement and provide infrastructure that will get us to the goal with rapid results. So, I want to end with this last slide which is, this is really what we are trying to achieve in a standard interoperability framework, trying to figure out how they can make sure that government, as a platform, can support the work of organizations and stakeholders like direct to come up with problems they want to solve and that we can provide a framework that helps collaborate around her organization, transparency, engagement, and rapid results so we can reuse the standards that are out there, that we can maintain consistency across the standards that are developed a way to make sure they fit into the needs that we have within the meaningful use words to make sure that we can drive us towards certification criteria as well. So with that, I am going to turn it back over to you, John, and see if there are questions or comments about what it is we are trying to do.
John Halamka: Thank you very much. I think all of us are very interested in providing coordination, oversight, and coronation to help you in this activity and it would seem that one of our collective risks is the application of a framework in the past has been Department of Homeland Security, Department of Justice, may have been there were less existent standards, less existent interfaces, maybe there were, a greater sense of urgency so it would be fascinating to see if you could take a framework that has worked successfully in government, which has slightly different environments, slightly different complexity slather different data models and wrapped into healthcare. I think all of your principles are very good but will it erase that as a risk in any, that you have on that risk.
Doug Fridsma: I think, you raise an important risk that is there. Indeed, in our experience that we have had with some of the early work, and looking at -- 32 and the like, we recognize there is perhaps more complexity than some of the problems we are trying to solve within healthcare than there are in some of the other kinds of data exchanges that are out there. I think we will have to be vigilant about that. I think part of what I have tried to emphasize is the process that we go through to come up with to the specifications is not that dissimilar to the kinds of processes we have within other standard organizations and certainly, those that have been used within -- some of the work that has gone on with HL seven and other organizations like MCI. You have a subtly nuanced differences some of them have different approaches to tackling those programs that I think there is consistency that there are certain things that you have to do and I am hopeful that the process will give us a framework to do that. And allow it to take the best from all of the different organizations and all of the different processes and incorporate them into a collaborative framework.
John Halamka: Thank you and let me open it up. I'm sure there are many questions.
Stan Huff: Does this stand. I like the overall approach and the collaborative nature and I guess where I have some confusion , I don't have a clear picture, maybe it's a better way to say it, is how, the interoperability framework interacting with the formal processes in the other standards development organizations and in particular, I'm thinking, if you needed a standard, to an extent, you may be able to rapidly make a new prototype or propose a new standard, does not need to go to ballot somewhere? Can you use the existing standard organizations balloting process or does ONC actually envision becoming a goober standard development organization where there would be a formal way of balloting those things within -- itself so I like the approach that I can see see the details of how those interactions are going to incur how you envision that.
Doug Fridsma: I think, the goal is to help ordinate across all of the different standard development organizations. I don't see this as being a goober standard organization in which there might be balloting all our this is going to replace the work of the STL. I think one of the things that is clear and we have seen us and many of the requirements that we have for meaningful use and the activities of healthcare reform is oftentimes we are faced with a possible try France to come up with a recommended set of standards for publication specifications or the like. It is useful to be able to have organizations that can come up with a potential standard or a potential way of exchanging information, very simple -- very similar to -- all those pieces that come together, what is going to be the transfer? What is going to be the content? What are going to be the values that the terminology then, you have the package and you can work with the -- to make sure those things can be ballot is an inappropriate way. That is what the vision would be. I think we are cognizant of the circular, a one a 119 the president of the framework, the government doesn't have the job of creating standards but rather identifying the need for standards and working with the SCO to make sure we have that. Much of this, framework, as an effort to create a common way of representing what those requirements will be, what the problems are we are trying to solve a created as a publication specifications that will be based around existing and perhaps standards that yet need to be. It and working with the FDA to make sure they get ballots appropriately.
Was questions?
Wes Rishel: This is less. -- Wes. I will try to disguise these, those questions. We really have a fuzzy set of distinctions between standards development organizations and profile her and force her organizations. Maybe a better way to say would be there is a continuum between standards, developers, profilers, and enforcers, three different kinds of organizations. And if we look at the current direct operation, for example, is more of a profiler. It didn't really define standards, decided how to pick among standards and create interfaces between the different kinds of standards. They arguably, IAG is a profiler. And -- as a profiler. And, the road was icy, one of the pluses of food Co. recruits although the big problems profile organizations have had, not being able to create a coherent publication they can only do that if it requires the right to intellectual property as part of the contract that you are working on. It has to have the ability crew to create works on its own. If you have the spectrum from SCO to profiler to certify her, you have a triangle pointing the other way about the links of time it takes for work that is started their to become actually practical as a means for health information exchange and that is where, as you pointed out, we have a tremendous amount of time pressure on making decisions, recognizing that from the start of an idea, for a new standard, to be practical for large scale implementation, unless it is a trivial topic, we're talking about a minimum of five years. So I think there needs to be some sort of visioning process as well that is looking downstream for standards that we will need when there is time to use the benefits of a consensus process to get a broad take out what the requirements are to what the possible solutions are.
Any comments?
Doug Fridsma: No, I like the distinction is made between profiler and enforcer. And I think trying to meet our legislative requirements with standard development and be able to support meaningful use, and be able to balance that with making sure we have engagement from all various participants is one of the motivations and reasons why we are trying to get something together in the interoperability framework. I will say, one thing that is a non-resolve the issue and this may be something that this committee can provide some input on, is the issue that was raised about intellectual property and engaging with the standards development organization. Clearly, that is a implementation in terms of how we work together with this. And that solving problems requires multiple groups to be able to come together and bring expertise to the table so that we have a comprehensive package that is useful to the implementers and the people trying to meet meaningful use, I think it will be important for us to get an array of engaging the FDA on making sure that we get a comprehensive policy, perhaps engage the STL is that they can contribute to those packages still be able to have business models that are available to support the work they do.
Wes Rishel: If I can repeat a rule of standards. When you change the consensus group, you change the consensus. And we have all of these issues about , if you take something that was developed violent group and ask a -- to endorse it, and the endorsement is meaningful, loss of change the standard. So you somehow need to create a collaboration process that the standards, the -- are obligated to effectively put up or shut up and say, we as they STL endorse this and it becomes an act of the STL are the SCO does not play. It is going to take some sort of active leadership here to get beyond I talk about difficulties that we had, not out at disrespect for the people who struggled hard to the do them but nonetheless, because of the struggles that they had.
To put commas, you have included the -- in the framework and the processor that is actually going to be a -- you're going to compete with some coordination there. One of the things I concur with what you said, it is important to think about the intellectual property issue because one of the reason people are confused by the version 2.5 implementation guide included -- was because that inclusion was actually through, interaction, see 83 which was referenced in C. 32 because of the fact that we cannot license all of this wind up with artifacts project artifacts pointing to artifacts that would be wonderful to have crisp, clear, artifacts and light and commercial properties for general use.
Of the commons?
Nancy Orvus: This Nancy John, I am glad you so but that was because that is the underlying issue, the business model and the financing of the continuing to standards and whatever. And I think also nine that as I said, one of the issues, federal, state, or local entities, they generally get a pass or endorsement from their government entity to participate because consensus-based standards are generally not as partisan are not exactly what they say, consensus-based but yes, we should definitely address the business financing model of intellectual property and development of -- and I would just say, also for those who are trying to help, as an organizational providers, or government agencies, it can be, or will become a bit fuel during on where to, all the various levels to the side truce truce was to provide input for, here are the projects or to supply bodies or ask for funding. We are looking very much forward to the next stage of this because it will certainly help us get a context in which to do the work that we all need to do.
The document will help a lot with that and Doug's intent is to circulate it to us when they get to a stage where it is more polished and therefore, we will have input into how all of this interacts and how we interact with it.
For those of us who have worked on integration, we love complexity,
But we definitely need some help, always communicating through leadership and decision makers.
Other comments on Doug's presentation?
Carol Diamond: This is Carol. I made this point many times in the past but I'm going to make it again and suggest that it is time to operationalize it. Many times I attacked on the interplay between policy and technology and why of a formation of standards, implementation and policy needs to be there in a visible and required way. My sense is that because they may process -- progress of the Tiger team recommendation exchange in the ONC framework is in place, those policy requirements need to actually get to be a part of the way you are contracting for some of this work to be done. In other words, it is okay to say privacy and security is an element we are working on but I think it really needs to be integrated into the approach of framework, and a very operational way and I think it is timely to start thinking about ways to do that. Interoperability and harmonization also apply to policy and out hate to see us get into a situation where the technology standards are the use cases are the implementation guide has to reworked or the policy objectives can be fulfilled because it's had core requirements were developed other things and I think that akin to parser work into policy and technology but from my perspective, listening to this today, and no a contractor out, it is the moment to start integrated news and a operational way.
The second point I want to make, just as you said, this is a platform for collaboration and innovation and I would argue it should be a platform for innovation and collaboration on some of the policy objectives that need to be fulfilled by technology so the Tiger team, needs recommendations on granular technology for consent and other things that really could be incorporated into this framework as a way to examine the policy objectives as well using technology and I would hate to see this silo that these are viewed as two separate areas or to separate strands of work and not brought together in a robust and meaningful way.
I think you are right that we should have a close coordination with policy and technology and let me give you a example of one of the challenges that I have and I think one of the things that we are trying to achieve on the technology side, there were may require us to make sure that we don't have a -- between policy and technology. Her go to the standards and interoperability framework is to have the ability to have data and service descriptions be reusable across multiple use cases. We have a granularity of the data elements that we described in a granularity in the services and we simply, which I take those things and create building blocks that -- it is important that policy work also thinks about things in modular driven approaches within a larger framework. I know that there has been work within the exchange to develop -- which is at large was a party agreement and that agreement, we have policies that are one-size-fits-all way to standards and services that are meant to be modular and are used, we start to get into the impedance mismatch between policy and technology and we have trouble doing exactly what you said, which is to make sure there is a close coronation within a --
I don't think the policy right now does in the way of a modular approach. In fact, the class form that you have for collaboration is a wonderful place to have it tested but I wanted to be clear about what I am urging you to do, which is to not say the technology and policy needs to be cored native but rather to say these are the policies of the technology and the standards and implementation guides, these are the policies they have to fulfill. I worry, if you don't do that, the policy work is an academic exercise and best case, worst case, it gets at the technical approach getting brief thought in the context of the policy down the road, which is also not an ideal outcome. I agree this interplay that is in both directions but that would be clear that because of the that the rating -- the policy committee and the Tiger team on another front, this is the moment because the Tiger team focused on stage one meaningful use of information exchange it because you are doing these contracts now for, to develop specifications and a technical model, has to be informed by at least a basic rubric and the other thing I will say, if you look at the platform for innovation on the technical front, you should look at a technical platform I policy up front and the kinds of problems and challenges that you mentioned, technically, can also be solved from a policy perspective from bringing the challenges to the same innovation platform and finding ways to solve them as opposed to two streams at different paces and every now and then there is the chicken and some will say this all work we're doing but the real number here is to be developed as a public policy perspective, has to be incorporated into the contractual and ONC sponsored approach or I worry that it may not come together.
Doug Fridsma: Valuable input. The policies would be integrated in the back to the comment the very least and hopefully multiple other checkpoints in the process.
We define a nationwide health information network as the data standard services and policies to support information exchange and so we need to figure out a way to make sure that happens and I think you are right, will likely happen at the beginning of the process through the cases and I think there is, we need to make sure we are vigilant about that.
Any other closing comments before we move on?
David McCallie: This is David. I have one question for Doug. Doug, one of the contracts was for reference implementation I'm curious, is an implementation of what? Of the tools are actual exchange services? Or some combination?
It is meant to be of the specifications that come out of the standards and interoperability framework. Again keep you a concrete example that is, the nationwide health information network as a series of specifications that describe the data services for using -- to provide that kind of exchange. We have FHA can act, which is a tool that, a piece of software that many people use it to help support exchanges in NHI and specifications that connecting, and another son, has made particular choices when it comes to option Audi and specifications. That means that there is although can act as agents of the specification, it may or may not be a, considered a reference implementation because they have chosen to, for example, implementing synchronous communications whereby the specifications talk about synchronous and asynchronous communication. The goal here is to have a one-to-one correspondence between specifications that we have for the nationwide information network ever meaningful use it to have a corresponding piece of software or code that actually implement that.
This sounds like an immense amount of software.
Doug Fridsma: I think, do it -- the rationality hope is that the reference implementation will be, will leverage much of the work that is being done in the past. They sure if it is read from consisting codes, those pieces that are part of that implementation. The goal is to not produce production level code the people could necessarily download directly but to make sure that we test our implementation specification and have gone through that particular exercise. Remember, we have open community that we have within the connects project and we are examining whether we can use similar mechanisms to help us with some of the work on rapid implementation following a model that has been successful at open sewers communities. Stewardesses Dixie Baker. I have a question. Have you established some of these questions that people brought up are really valid considerations. Have you established milestones and metrics for actually measuring and taking the process along the way?
That is one of the first charges of the various people that are working on the contract. Essentially, establish metrics, milestones interests to have the availability to track progress to this and trying to integrate a lot of that work into the ongoing operation within the coordinator and those things are part of the blue want to try to do with this work. Most of the contracts have been awarded within the last three weeks. There is lots of room for us to be able to take feedback and suggestions, recommendations, and include it in the work that is just beginning.
Metrics and milestones for the overall means progress were each of these processes?
It is both of those and obviously, the lower-level metrics, needs to fit into the overall goals we have for meaningful use. There needs to be a rolling up of metrics to make sure they are satisfying the overall objectives of the office.
David Tao of Siemens was able to ask a question at the end of the meeting about the projected availability of the CONOPS document.
Doug Fridsma: I think you are right, this will help us tie all of these pieces together. We have a document that we have been working on that we are beginning to circulate to see if there are pieces that are missing. We have been coordinating with some of the other organizations, particularly with some of the people from -- to see that we have a consistent view of the world and we also have a working with some of the people from HHS to have participated as well. I think there is wide to be something out of the next few weeks and I expect it will be at a level of detail that will be higher than most people are going to want and in part, before we walk down entirely, we will have some thoughtful public input to make sure we have coordination strategies right. That is one of the key parts of this and I think until we have all of our contract awarded, it is going to be difficult for us to have that it has finalized version.
My own question went unaddressed, which I'll attribute to technical issues [although I submitted via phone and web] and not to any editorializing by the FACA. It's basically this:
How will ONC ensure coordination and communication between these 11 different contracts without becoming a bottleneck. I remember back to a time in a previous administration where all communciation between HITSP, CCHIT, NHIN, HITSC and AHIC went through ONC, and the complete disaster that was for coordination. My hope is that the new ONC [with about 10 times the staff] will do better, but also will be neither a filter or a restrictor of communications. The answer may well be in the CONOPS document that David Tao referenced.
Keith, the real-time transcription of the meeting sometimes leaves a bit to be desired. What I actually said was not "Wes. I will try to disguise these, those questions" but "I will not try to disguise these comments as questions."
ReplyDeleteSorry about that Wes. I could have even found and fixed that one, but there were so many others that I wouldn't get, so to be fair, I didn't fix anything.
ReplyDeleteWhen the actual transcript is posted maybe I can grab that and update this page.
The transcript does require close and cautious reading...