Dan wants to know what the difference between a C32, a Patient Summary, and a Summarization of Episode document is. This is a really GOOD question.
So, let's take these in reverse order.
A Summarization of Episode Document (or Note as it appears in LOINC) is a document that summarizes an episode of care for a patient. That brings in two questions:
What is a summary, and what is an episode?
Wictionary gives us "concise, brief or presented in a condensed form" for summary, and "incident or action standing out by itself, but more or less connected with a complete series of events." for episode. These are good enough to explain what a summary of episode note is. It is a concise or brief note describing an incident in the care of a patient. It isn't every detail, or even a life history, though it can be and has been stretched to cover both these extremes.
A Patient Summary is any of a variety of clinical notes which provides a summary of information about a patient. It may involve an episode of care or not. Patient summaries include History and Physical Notes, Consult Notes, Summary of Episode Notes, Discharge Summaries, Transfer Summaries, and Progress Notes. The key point is that it contain a summary, and not every last detail.
The ANSI/HITSP C32 is a Patient Summary that uses the HL7 Continuity of Care Implementation Guide. That guide specifies that the document type be coded as a "Summary of Episode" note, that being the closest thing in LOINC to what the intent of the CCR was when it was harmonized with CDA through the CCD. So, the C32 is a Patient Summary, and is a Summarization of Episode Note (or Document). It isn't the only way to summarize an episode (a Discharge summary is a very specific summarization of an inpatient episode of care), but in the US, under meaningful use, it is something that will be needed for just about every encounter.
Tuesday, August 31, 2010
Monday, August 30, 2010
The ONC Interoperability Framework Part II
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.
Sunday, August 29, 2010
The ONC Interoperability Framework
Below are the 10 contracts that John Halamka mentions in his post on the ONC Interoperability Framework
In the meantime, here is what I want to know about the ONC Interoperability Framework:
Monday Morning Update:
Erik Pupo provided more information below, which I was able to verify and add links for.
Dr. Doug Fridsma will be discussing the ONC Standards and Interoperability Framwork today at 11:30 Eastern on the HIT Standards call.
His presentation also appears below:
Items in green have been awarded, and the link will take you to the award announcement or press release. Items in red have not been awarded, but the link will take you to the announcement. Items in black I have no news on. The invisible 11th item that John mentioned I also have no news on.
- Use case development and functional requirements for interoperability
- Harmonization of standards and interoperability specifications
- Standards Development (To be recompeted per Doug Fridsma slides below)
- Tools and Standards Repository
- Interoperability Specifications
- NHIN Architecture Refinement and Management
- Reference Implementation (updated per Erik below)
- Integration Testing (updated per Erik below)
- NHIN Demonstrations and Emergent Pilots (updated per Erik below)
- NHIN Operations and Infrastructure
In the meantime, here is what I want to know about the ONC Interoperability Framework:
- Who will determine use cases, and how will experts from the healthcare industry be engaged in sketching out the use cases?
- How much of the use case development will come from public input?
- Will use case developers be available to discuss their thoughts and intentions with downstream users of these deliverables?
- How will vendors, providers, Standards and profiling organizations be engaged in the standards harminization process?
- For standards development, how will ONC ensure that public input is available EARLY in design processes before proposed standards are discussed with SDOs? Prior experience with contracted standards effort shows that unless a concerted effort is made to incorporate public input on design and architecture BEFORE text is written leads to results that are difficult to change after significant writing is accomplished.
- I've got a lot of questions about interoperability specifications, but those most important ones are what has ONC learned about the mistakes that HITSP made in the past, and how will these be addressed? Most notable of these is how will ONC make it easier for implementers to implement without having to peal the onion, and how will this effort be coordinated with tools and the standards repository?
- On Reference implementations, I want ONC to tell me how they will ensure that implementors will be engaged in the specification development alongside industry, without needless barriers.
- I'd also like to understand what policies will be put into place on reference implementations for use. My tax dollars are paying for this, I want the code to be freely available to all, but I don't want it to be made available in a way that it cannot be used commercially either.
- For integration testing, I'd like to understand how the integration testing process and feedback from it will be incorporated into the specification development, standards and harmonization processes?
- Like John Moehrke, I too am concerned about Reuse and legacy, but I want to the put the question in terms of cost and value. What processes will ONC put into place to establish the value and cost of change? HITSP had a "cost" column in its assessment of standards, but that issue was never addressed in the HITSP process. It had been in the original intent of the HITSP Tier 2 standards selection process to evaluate this, but because it was never included, it was never discussed. This will be a hot button issue, and not addressing it openly and transparently will hamper harmonization or development efforts. It's a tricky issue to address, but it needs to be done and done well.
- Coordinating 11 different contracts will be no easy task. What processes will ONC put into place to ensure that they do not become the bottleneck in communications, and how will they ensure that open and transparent discussions can be had among all participants? If you want agile development, you will need to enable agile processes, and that also means agile communications.
- Finally, how will people like me, others in the healthcare provider sector, who have been engaged in standardization efforts over the last decade (or longer for others) be able to participate in this processes?
Monday Morning Update:
Erik Pupo provided more information below, which I was able to verify and add links for.
Dr. Doug Fridsma will be discussing the ONC Standards and Interoperability Framwork today at 11:30 Eastern on the HIT Standards call.
His presentation also appears below:
Friday, August 27, 2010
Announcement of Additional Ballot Openings and Several Withdrawn Ballots for the HL7 September 2010 Ballot Cycle
HL7 Members,
This is a follow-up announcement to the initial announcement of ballot openings release earlier this week. The updated PDF document linked to below indicates several ballot pools that are opening and several more that have been postponed for the September 2010 ballot cycle. These items are summarized below.
ADDITIONAL BALLOT OPENINGS FOR FRIDAY AUGUST 27TH
The draft standards/documents being balloted are associated with Clinical Document Architecture, Release 2. The ballots opening today are:
- HL7 Implementation Guide for CDA Release 2 - Level 3: Healthcare Associated Infection Reports, Release 6 - US Realm (1st DSTU Ballot)
- HL7 Implementation Guide for CDA Release 2: Progress Note, Release 1 - US Realm (1st DSTU Ballot)
- HL7 Implementation Guide for CDA Release 2: greenCDA Modules for CCD, Release 1 (1st Informative Ballot)
For additional information about these ballots, please refer to the linked PDF document. Given the size of the announcement document, it is not embedded directly in this e-mail but can be downloaded from this link:
BALLOTS WITHDRAWN FOR THIS CYCLE
Please note that the Version 3 Pharmacy ballots scheduled for this cycle have been postponed and withdrawn from balloting. These ballots include:
- HL7 Version 3 Standard: Pharmacy CMETs, Release 10 (Unique Ballot ID: V3_RX_CMET_R10_N4_2010SEP)
- HL7 Version 3 Standard: Pharmacy; Common Dispense and Supply Event, Release 1 (Unique Ballot ID: V3_RX_CDSEVNT_R1_N2_2010SEP)
- HL7 Version 3 Standard: Pharmacy; Common Order, Release 1 (Unique Ballot ID: V3_RX_CMNORDER_R1_N2_2010SEP)
- HL7 Version 3 Standard: Pharmacy; Medication Dispense and Supply Event. Release 1 (Unique Ballot ID: V3_RX_MDSEVNT_R1_N4_2010SEP)
- HL7 Version 3 Standard: Pharmacy; Medication Knowledge-Base Query, Release 1 (Unique Ballot ID: V3_ME_DKBQ_R1_N4_2010SEP)
- HL7 Version 3 Standard: Pharmacy; Medication Administration Event and Administration Statement, Release 1 (Unique Ballot ID: V3_RX_MSSEVNT_R1_N3_2010SEP)
Important Notes
-- Ballot Closing: All ballots are scheduled to close on Monday, September 27th, 2010.
-- Ballot pool signup is available now and will remain open until a week from ballot closing. For this cycle, the signup close date is Monday, September 20th, 2010. This is also the closing date for enrollment in Non-Member Participation in the ballots for this cycle. Instructions detailing Non-Member Participation for non-members are posted in the announcements section of the Ballot Desktop. Ballot Pools are available for sign-up on the Ballot Desktop (http://www.hl7.org/ctl.cfm?action=ballots.home)
Please review the linked document for the full ballot announcements and related details.
Thursday, August 26, 2010
Top O' the Week
So I'm procrastinating getting back to writing the CDA Book and thought I'd prep the Top O' the week. Still haven't had time to deal with yearly or all time stats, and I'm probably not going to bother. By the time I have enough time to do it, I'll have six months of stats for this year via Blogger Stats, and that will be good enough going forward.
The top post this week was Monday's Rant on The definition of Transparency is apparently Invisibility. That particular post also hit another record for me which is that it hit the second or third-largest audience on twitter of any post (I cannot really tell because twitter doesn't yet have decent analytics, and backtype.com and backtweets.com and other sites don't do a good job resolving all the hits). It also apparently wound up in the inbox of a few people inside ONC, which is of course what I was after in the first place. The NHIN Spec Factory call today shed a bit more light on the topic, but not enough yet (are you still listening ONC?).
I shouldn't be too hard on ONC. After all, it was neither ONC nor HHS that set most of these deadlines. For that we'd have to thank congress, and frankly, I'd rather crazy deadlines trying to do something than spend another 10 years waiting for it to get done.
Top of the month ranks haven't changed since last week, but the Meaningful Use Standards Summary stats have slipped from 1000 hits to about 650. The other two are still hanging on steady at around 300 hits.
The top post this week was Monday's Rant on The definition of Transparency is apparently Invisibility. That particular post also hit another record for me which is that it hit the second or third-largest audience on twitter of any post (I cannot really tell because twitter doesn't yet have decent analytics, and backtype.com and backtweets.com and other sites don't do a good job resolving all the hits). It also apparently wound up in the inbox of a few people inside ONC, which is of course what I was after in the first place. The NHIN Spec Factory call today shed a bit more light on the topic, but not enough yet (are you still listening ONC?).
I shouldn't be too hard on ONC. After all, it was neither ONC nor HHS that set most of these deadlines. For that we'd have to thank congress, and frankly, I'd rather crazy deadlines trying to do something than spend another 10 years waiting for it to get done.
Top of the month ranks haven't changed since last week, but the Meaningful Use Standards Summary stats have slipped from 1000 hits to about 650. The other two are still hanging on steady at around 300 hits.
- Meaningful Use Standards Summary
- Can you imagine this nurse on a Harley?
- And the next Ad Hoc Motorcycle Guy Harley Award goes to...
There have been a couple of new additions to the @motorcycle_guy stream also this week, thanks to some first rate work by Mike Kingery at HL7. There are two new RSS feeds up on the HL7 Web site and one existing one which I've harnessed into my twitter stream via twitterfeed.com. Now whenever there's a new HL7 standard, press release or event, it will be autotweeted.
For any tweeps that want to do the same, the RSS Feeds are:
HL7 Press Releases: http://www.hl7.org/press/hl7feed2rss.xml
HL7 Meetings and Events: http://www.hl7.org/press/hl7feed2rss.xml
HL7 International ANSI Approved Standards: http://www.hl7.org/rss/ansiApprovedStandards.rss
You can reburn the feed using Feedburner and then set it up to auto-tweet, or you can use twitterfeed.com to do the same (I use both for different feeds).
Next up is hooking in IHE, but first I have to get them to use RSS on their web-site.
Finally, it's worth mentioning that the stats that I post now could change by tomorrow soon as people start reading tomorrow's edition of HISTalk. It seems that someone (namely me) forwarded @IngaHIStalk my blog post on changes needed for Public Health Standards in Meaningful Use. If you click, read the comments as well.
That's all for now, back to writing (The Book).
What is the NIEM?
I spent an hour today on an NHIN Spec Factory call learning about the NIEM. The presentation appears here (Slideshare hated it at 5Mb, so its now on Google Docs). The NIEM is as you have probably heard, what ONC believes to be the framework around which their Standards Harmonization contracts that John Halamka blogged about a few months ago. This was an effort from ONC in the socialization of the Standards framework using the NIEM that was at least partially successful and gets good (but not great) marks from me. It was certainly better than the silence we've been hearing.
I heard a lot of familiar terms: Use Cases, Gaps, Overlaps, Standards Evaluation ... sounded very much like HITSP. But also many familiar processes from IHE (including testing), and the focus on model driven development makes me think that HL7 has quite a bit of expertise to offer as well
Some differences: Pilots and Referece Implementations... The latter are something that is required by OASIS standards before they can become final. Also, the inclusion of interim deliverables and interative ("agile") development. The key to agile is not let it become "we don't know what we are doing so we are going to wing it" development. That's a real danger. You need to have documented processes.
Another big difference is all documentation in one place for an information exchange package. That's something we all wanted out of HITSP but they didn't have the funding to implement.
According to the presenter, ONC doesn't want to write brand new specs, they want to reuse existing work.
It's all got to fit together, and apparently the communications failure out of ONC is in part a result of trying to line up 10 different ducks in a row. Not all of the contracts have been awarded, so it's a bit difficult to communicate about everything at once.
Uhuh. This is project management 101 guys, and you need to learn to be agile too. Agile means being able to change your tactics when the situation changes. If you cannot manage that, how will you manage 10 different inter-related projects. I don't need to go back over what a disaster the communications bottleneck was for the AHIC, HITSP, HISPC, NHIN and CCHIT projects was for the first couple of years under Bush's ONC? Surely this ONC can do better than that
All in all, I feel better today than I did on Monday, although a few slides did give me some pause. After digging into the slide that talked about "HHS creating a Health Information Model" it was clear that as one person put it "ONC poorly worded" this slide. I understand their intent, HHS will fund a program to do it with industry and SDO input, begging, borrowing and reusing whatever they can.
There are a lot of places that NIEM hasn't been yet. Web Services that don't use WSDL (e.g., DICOM), dealing with an industry that has a large installed legacy base, et cetera. This is going to be a learning process for everyone.
OK, so better marks today than previously, and we are all learning as we go. I hope Dr. Fridsma is a quick study.
I heard a lot of familiar terms: Use Cases, Gaps, Overlaps, Standards Evaluation ... sounded very much like HITSP. But also many familiar processes from IHE (including testing), and the focus on model driven development makes me think that HL7 has quite a bit of expertise to offer as well
Some differences: Pilots and Referece Implementations... The latter are something that is required by OASIS standards before they can become final. Also, the inclusion of interim deliverables and interative ("agile") development. The key to agile is not let it become "we don't know what we are doing so we are going to wing it" development. That's a real danger. You need to have documented processes.
Another big difference is all documentation in one place for an information exchange package. That's something we all wanted out of HITSP but they didn't have the funding to implement.
According to the presenter, ONC doesn't want to write brand new specs, they want to reuse existing work.
It's all got to fit together, and apparently the communications failure out of ONC is in part a result of trying to line up 10 different ducks in a row. Not all of the contracts have been awarded, so it's a bit difficult to communicate about everything at once.
Uhuh. This is project management 101 guys, and you need to learn to be agile too. Agile means being able to change your tactics when the situation changes. If you cannot manage that, how will you manage 10 different inter-related projects. I don't need to go back over what a disaster the communications bottleneck was for the AHIC, HITSP, HISPC, NHIN and CCHIT projects was for the first couple of years under Bush's ONC? Surely this ONC can do better than that
All in all, I feel better today than I did on Monday, although a few slides did give me some pause. After digging into the slide that talked about "HHS creating a Health Information Model" it was clear that as one person put it "ONC poorly worded" this slide. I understand their intent, HHS will fund a program to do it with industry and SDO input, begging, borrowing and reusing whatever they can.
There are a lot of places that NIEM hasn't been yet. Web Services that don't use WSDL (e.g., DICOM), dealing with an industry that has a large installed legacy base, et cetera. This is going to be a learning process for everyone.
OK, so better marks today than previously, and we are all learning as we go. I hope Dr. Fridsma is a quick study.
HL7 to Offer Program on Standards for MeaningfulUse of EHR Technology at Annual Meeting
This crossed my desk this morning, which was right on time since I submitted the draft yesterday ;-)
This will be a great program for those of you in the Boston/Cambridge area on October 4th. HL7 experts will be describing the 5 HL7 Standards selected for meaningful use. I'll be speaking on CCD and CDA as you see below, and we've lined up experts and excellent speakers on the other HL7 standards.
Keith
This will be a great program for those of you in the Boston/Cambridge area on October 4th. HL7 experts will be describing the 5 HL7 Standards selected for meaningful use. I'll be speaking on CCD and CDA as you see below, and we've lined up experts and excellent speakers on the other HL7 standards.
Keith
Health Level Seven® International
For Immediate Release
HL7 to Offer Program on Standards for Meaningful Use of EHR Technology at Annual Plenary and Working Group Meeting
Ann Arbor, Michigan, USA – August 26, 2010 – Health Level Seven® International (HL7®), the global authority for interoperability and standards in healthcare information technology, today announced the speakers for their Ambassador program on Standards for Meaningful Use being held Monday, October 4, 2010 in Cambridge, MA. This program qualifies for three Continuing Medical Education credits (CME) approved through the American College of Physicians and provides an overview of the HL7 standards used to achieve meaningful use under the new federal regulations.
“As the healthcare industry is pushed forward to meet the meaningful use requirements under the ARRA-HITECH act, healthcare IT professionals and healthcare providers will have to work together to integrate computer systems and share patient data,” said Grant M. Wood, Senior IT Strategist at Intermountain Healthcare’s Clinical Genetics Institute in Salt Lake City, and host of the program. “HL7 has solutions – from sharing lab data, to sharing summary data about a patient as they move from doctor to doctor, to even those who provide public health services like disease surveillance and immunization registries. This multi-topic session will help budding experts achieve this goal.”
The program includes:
- HL7 and Meaningful Use by Gora Datta, Chairman and CEO, CAL2CAL Corporation. Mr. Datta will provide an overview of what meaningful use requires, and how HL7 has been involved in the development of standards for meaningful use.
- HL7 Version 2 and Immunization by Alean Kirnak, President, Software Partners LLC; American Immunization Registry Association; Co-Chair, HL7 Public Health and Emergency Response Work Group. Ms. Kirnak will describe the approaches to meeting Meaningful Use immunization registry reporting criteria using HL7 Version 2. She will discuss the place of immunization registry reporting within the overall context of the meaningful use rule, as well as the potential future benefits to providers.
- HL7 Version 2 and Surveillance by Lori Reed-Fourquet, Consultant, eHealthSign, LLC and Anna Orlova, PhD, Executive Director, Public Health Data Standards Consortium Ms. Reed-Fourquet and Dr. Orlova will describe standards and approaches for meeting meaningful use requirements involving public health surveillance. They will discuss both provider and public health perspectives for bi-directional interoperable communications using multiple HL7-based messages, documents, and services.
- HL7 Version 2 and Electronic Lab Reporting by Austin Kreisler, Technical Fellow, SAIC; Co-Chair, HL7 Orders & Observations Work Group; Co-Chair, HL7 Domain Experts Steering Division; Member, HL7 Technical Steering Committee. Mr. Kreisler will describe the relationship between meaningful use and the reporting of laboratory result data to public health agencies. This presentation will describe the various ways laboratory result data are utilized by public health agencies and show how HL7 standards are used to facilitate use of that laboratory data.
- HL7’s CDA and CCD Standards by Keith W. Boone, Standards Architect, GE Healthcare; Co-Chair, HL7 Clinical Document Architecture Work Group; Co-Chair, IHE Patient Care Coordination; past Co-Chair, ANSI/HITSP Care Management and Health Records. Mr. Boone will describe the use of the HL7 CDA standard and CCD implementation guide to create clinical summaries and exchange health information between eligible providers and hospitals. This session will also address the use of the HITSP C32 specification to the HL7 standards and guides.
The Ambassador Program event on HL7 and the final rule on standards for meaningful use will be held Monday afternoon immediately following the plenary meeting. For more information about this session, please visit http://www.hl7.org/events/boston102010/ambassador.asp. Additional tutorials providing more detail on HL7 standards for meaningful use, including HL7 Version 2, CDA Release 2 and CCD, are offered throughout the week. For more information about HL7 tutorials, please visit http://www.hl7.org/events/boston102010/tutorials.asp.
Online registration is now open. Early bird registration offers a discounted rate through September 10, 2010. To register online, visit http://www.hl7.org/events/boston102010/. Advance registrations will be accepted until September 24, 2010. After September 24, 2010, registrations must be made on-site in Cambridge, MA.
HL7 Working Group meetings are held three times a year to provide its more than 40 work groups a chance to meet together to work on the standards and provide educational sessions for the healthcare IT community.
About Health Level Seven International (HL7)
Founded in 1987, Health Level Seven International is the global authority for healthcare Information interoperability and standards with affiliates established in more than 30 countries. HL7 is a non-profit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7’s more than 2,300 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving healthcare. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.
HL7’s endeavors are sponsored, in part, by the support of its benefactors: Abbott; Accenture; Booz Allen Hamilton; Centers for Disease Control and Prevention; Duke Translational Medicine Institute (DTMI); Eclipsys Corporation; Epic Systems Corporation; European Medicines Agency; the Food and Drug Administration; GE Healthcare Information Technologies; GlaxoSmithKline; Intel Corporation; InterSystems Corporation; Kaiser Permanente; Lockheed Martin; McKesson Provider Technology; Microsoft Corporation; NHS Connecting for Health; NICTIZ National Healthcare; Novartis Pharmaceuticals Corporation; Oracle Corporation; Partners HealthCare System, Inc.; Pfizer, Inc.; Philips Healthcare; Quest Diagnostics Inc.; Siemens Healthcare; St. Jude Medical; Thomson Reuters; the U.S. Department of Defense, Military Health System; and the U.S. Department of Veterans Affairs.
Numerous HL7 Affiliates have been established around the globe including Argentina, Australia, Austria, Brazil, Canada, Chile, Colombia, Croatia, Czech Republic, Finland, Germany, Greece, Hong Kong, India, Italy, Japan, Korea, The Netherlands, New Zealand, Norway, Romania, Russia, Singapore, Spain, Sweden, Switzerland, Taiwan, Turkey, United Kingdom, and Uruguay.
For more information, please visit: http://www.hl7.org/
# # #
A Change of Mood
I get a little tired of my complaining on Monday and Tuesday and so today's post is about the topic of mood in HL7 Version 3. The HL7 moodCode attribute is one of those topics that always seems to confuse people because the name doesn't seem to make any sense. And it's true, it doesn't until you understand which definition of mood you need to work with. This is the definition you want to work with.
Since just about every clinical statement (sentence) you can make in HL7 version 3 starts with a verb (an Act), you have to have different ways to inflect these verbs. Inflection changes mood and tense, and that's what moodCode is all about. And just as in linguistics, where mood and tense are conflated, they are also conflated in HL7 Version 3.
Their are something like 18 moods defined in the HL7 moodCode vocabulary (there were only 14 when CDA Release 2 was created). Moods fall into two main categories: The Act completion track represents transitions from definition (e.g., a clinical guideline for care), to intent (a plan of care), to event (a sequence of care events that have taken place). The predicate track deals with more nebulous moods.
So, looking at a few mood codes, what would be the appropriate linguistic mood to associate with each one? Here are my best guesses.
Event (EVN) - The actual occurence of an event. Indicative.
Request or Order (RQO) - A request or order to perform an act [in the future]. Precative or Imperative.
Definition (DEF) - a definition of an act that can occur. Deontic
Intent (INT) - The intent for an act to occur [in the future]. [Future tense]
Proposal (PRP) - A proposal to perform an act [in the future].
Promise (PRMS) - The promise to perform an act [in the future]. Commissive
Event Criteria (EVN.CRT) - An event that must occur or criteria that must be applicable before another event can happen. Conditional [but note that HL7 the inflection occurs on the verb in the protasis, so perhaps it is Subjective]
Expectation (EXPEC) - The expectation that something may occur in the future. Potential seems to be the best choice.
Goal (GOL) - The hope, expectation or desire that something does occur in the future. Optative
Risk (RSK) - The hope, expectation or desire that something DOES NOT occur in the future. Optative
I'm glad HL7 chose to use something humans can understand in the vocabulary for moodCode, because this little experiment just proved that I've forgotten a ton about mood, and never learned quite a bit more.
Of course, just when you thought you understood it all, things change. It turns out the criteria moods are defective, and so the CRT and EVN.CRT mood code was recently deprecated. I'll save the discussion of that for another post.
I had thought this would be book fodder if I had been able to understand it better. [Pluperfect subjunctive?].
mood (plural moods)Now, in a former life I used to write linguistic software. I helped develop applications for spelling correction, grammar and thesaurus applications that are still in use today in Microsoft Word, among others. So I should know a little something about mood. But while that life led to this one, I found that I needed a refresher on the topic. A more detailed explanation of mood as used in linguistics can be found on wikipedia.
- (grammar) A verb form that depends on how its containing clause relates to the speaker’s or writer’s wish, intent, or assertion about reality.
Since just about every clinical statement (sentence) you can make in HL7 version 3 starts with a verb (an Act), you have to have different ways to inflect these verbs. Inflection changes mood and tense, and that's what moodCode is all about. And just as in linguistics, where mood and tense are conflated, they are also conflated in HL7 Version 3.
Their are something like 18 moods defined in the HL7 moodCode vocabulary (there were only 14 when CDA Release 2 was created). Moods fall into two main categories: The Act completion track represents transitions from definition (e.g., a clinical guideline for care), to intent (a plan of care), to event (a sequence of care events that have taken place). The predicate track deals with more nebulous moods.
So, looking at a few mood codes, what would be the appropriate linguistic mood to associate with each one? Here are my best guesses.
Event (EVN) - The actual occurence of an event. Indicative.
Request or Order (RQO) - A request or order to perform an act [in the future]. Precative or Imperative.
Definition (DEF) - a definition of an act that can occur. Deontic
Intent (INT) - The intent for an act to occur [in the future]. [Future tense]
Proposal (PRP) - A proposal to perform an act [in the future].
Promise (PRMS) - The promise to perform an act [in the future]. Commissive
Event Criteria (EVN.CRT) - An event that must occur or criteria that must be applicable before another event can happen. Conditional [but note that HL7 the inflection occurs on the verb in the protasis, so perhaps it is Subjective]
Expectation (EXPEC) - The expectation that something may occur in the future. Potential seems to be the best choice.
Goal (GOL) - The hope, expectation or desire that something does occur in the future. Optative
Risk (RSK) - The hope, expectation or desire that something DOES NOT occur in the future. Optative
I'm glad HL7 chose to use something humans can understand in the vocabulary for moodCode, because this little experiment just proved that I've forgotten a ton about mood, and never learned quite a bit more.
Of course, just when you thought you understood it all, things change. It turns out the criteria moods are defective, and so the CRT and EVN.CRT mood code was recently deprecated. I'll save the discussion of that for another post.
I had thought this would be book fodder if I had been able to understand it better. [Pluperfect subjunctive?].
Wednesday, August 25, 2010
MeaningfulUse IG for Public Health Surveillance likely to Change
Meaningful Use selects a number of different standards and implmentation guides. Here's what it has to say about Public Health Surveillance:
1.1 SCOPE
This document specifies the structure and methodology for the use of the Health Level 7 (HL7) Version 2.5 Unsolicited Result Message (ORU^R01) to support electronic interchange of any de-identified Nationally Notifiable Condition message from public health entities to the CDC. The message structure is the same for the individual Case Notification, the Summary Notification, the Environmental Investigation Notification, and the notification of Laboratory report results to meet national reporting requirements to CDC.
On followup with experts from a state public health agency, we heard that this was wrong on several counts:
So what is an implementor to do while we wait for CDC and the rest to find the right solution, and for ONC to announce that there really is a problem and that it will be fixed?
Well, here's my advice:
1. Use HL7 Version 2.3.1, because there is no implementation guide specified, and you can do something reasonable with it.
2. Use the message formats defined in HITSP C39 Encounter Message Component, which is designed (in 2006 I might add) for the purpose of "sending patient encounter data (excluding laboratory, radiology) from a Biosurveillance Message Sender to a Biosurveillance Message Receiver.", but change the version from 2.5 to 2.3.1
This should be compliant with §170.205 (d)(2) (it will be an HL7 Version 2.3.1 message) and §170.302 (l) (by compliance with §170.205 (d)(2)).
Now, what should CDC and ONC do?
§170.205 Content exchange standards and implementation specifications for exchanging electronic health information. The Secretary adopts the following content exchange standards and associated implementation specifications:
...
(d) Electronic submission to public health agencies for surveillance or reporting.
(1) Standard. HL7 2.3.1(incorporated by reference in §170.299).
(2) Standard. HL7 2.5.1(incorporated by reference in §170.299).
Implementation specifications. Public Health Information Network HL7 Version 2.5 Message Structure Specification for National Condition Reporting Final Version 1.0 and Errata and Clarifications National Notification Message Structural Specification (incorporated by reference in §170.299).
§170.302 General certification criteria for Complete EHRs or EHR Modules. The Secretary adopts the following general certification criteria for Complete EHRs or EHR Modules. Complete EHRs or EHR Modules must include the capability to perform the following functions electronically, unless designated as optional, and in accordance with all applicable standards and implementation specifications adopted in this part:
...
(l) Public health surveillance. Electronically record, modify, retrieve, and submit syndrome-based public health surveillance information in accordance with the standard (and applicable implementation specifications) specified in §170.205(d)(1) or §170.205(d)(2).One of the teams that was looking to implement this internally discovered a number of issues with this selection. In reviewing the PHIN specification, we found this [emphasis mine]:
1.1 SCOPE
This document specifies the structure and methodology for the use of the Health Level 7 (HL7) Version 2.5 Unsolicited Result Message (ORU^R01) to support electronic interchange of any de-identified Nationally Notifiable Condition message from public health entities to the CDC. The message structure is the same for the individual Case Notification, the Summary Notification, the Environmental Investigation Notification, and the notification of Laboratory report results to meet national reporting requirements to CDC.
On followup with experts from a state public health agency, we heard that this was wrong on several counts:
- This specification describes a framework for public health reporting from states to the CDC, not for reporting to state public health.
- It's an old version (Version 2.0 is out).
- It describes a framework for communication but doesn't describe what goes into the message. One observer reported: "It specifies what the picture frame should look like, but not what the picture should be that goes in it."
So what is an implementor to do while we wait for CDC and the rest to find the right solution, and for ONC to announce that there really is a problem and that it will be fixed?
Well, here's my advice:
1. Use HL7 Version 2.3.1, because there is no implementation guide specified, and you can do something reasonable with it.
2. Use the message formats defined in HITSP C39 Encounter Message Component, which is designed (in 2006 I might add) for the purpose of "sending patient encounter data (excluding laboratory, radiology) from a Biosurveillance Message Sender to a Biosurveillance Message Receiver.", but change the version from 2.5 to 2.3.1
This should be compliant with §170.205 (d)(2) (it will be an HL7 Version 2.3.1 message) and §170.302 (l) (by compliance with §170.205 (d)(2)).
Now, what should CDC and ONC do?
- Fess up. Everyone makes mistakes. Please correct this one swiftly, and with as much transparency as you possibly can. We don't need heads to roll. Meaningful Use has amazingly crazy schedules that we are all trying to meet. Make it possible for us to meet them by giving us the information we need, when you know it, not after you've had a change to make it all better. Cause by then, it will already be too late.
- Give us a schedule for when you think the correction will be made.
- Consider seriously using the HITPS C39 specification which was purpose designed for this specifc use case for the replacement. I'll point out that the HITSP C39 guide had the input of experts from the CDC and Federal Advisory Committees conveigned on this topic, and State Public Health agencies.
Tuesday, August 24, 2010
The definition of Transparency is apparently Invisibility
Recently I ran into a friend who has some knowledge of the Standards Harmonization contract solicted under task order 10-233-SOL-00072 to HHS. He told me that Deloitte has been awarded the contract (as of August 12th according to FedBizOps.gov).
According to the solicitation: The purpose of this requirement is to obtain Contractor support services to harmonize standards and interoperability specifications to achieve ubiquitous implementation of standards, promote wider use of standards, and increased level of interoperability across the nation in health information technology (HIT). The overall purpose of the Office of the National Coordinator for Health Information Technology (ONC) programs is to facilitate and expand the secure, electronic movement and use of health information among organizations according to nationally recognized standards.
So is anyone else worried that we [members of healthcare SDO's and Standards Profiling organizations] haven't heard anything about this?
According to the solicitation: The purpose of this requirement is to obtain Contractor support services to harmonize standards and interoperability specifications to achieve ubiquitous implementation of standards, promote wider use of standards, and increased level of interoperability across the nation in health information technology (HIT). The overall purpose of the Office of the National Coordinator for Health Information Technology (ONC) programs is to facilitate and expand the secure, electronic movement and use of health information among organizations according to nationally recognized standards.
So is anyone else worried that we [members of healthcare SDO's and Standards Profiling organizations] haven't heard anything about this?
Monday, August 23, 2010
IHE News: North American Connectathon Registration Opens
Seems to be the day for press releases...
IHE Community,
IHE North American Connectathon Applications Due October 8
The IHE North America Connectathon will take place January 17-21, 2011 in Chicago. Applications for testing participants are available online at www.ihe.net/north_america/connectathon2011.cfm. The submission deadline is Friday, Oct. 8, 2010.
The Connectathon is the healthcare IT industry's largest face-to-face interoperability testing event. IHE profiles enable effective interoperability in a wide range of clinical settings, including health information exchanges. They also support many of the objectives for "meaningful use of electronic health records" advanced by the Health IT Standards Committee of the US Office of the National Coordinator for Health IT.
At this year's Connectathon, IHE profiles in the following domains will be tested:
IHE Community,
IHE North American Connectathon Applications Due October 8
The IHE North America Connectathon will take place January 17-21, 2011 in Chicago. Applications for testing participants are available online at www.ihe.net/north_america/connectathon2011.cfm. The submission deadline is Friday, Oct. 8, 2010.
The Connectathon is the healthcare IT industry's largest face-to-face interoperability testing event. IHE profiles enable effective interoperability in a wide range of clinical settings, including health information exchanges. They also support many of the objectives for "meaningful use of electronic health records" advanced by the Health IT Standards Committee of the US Office of the National Coordinator for Health IT.
At this year's Connectathon, IHE profiles in the following domains will be tested:
- Anatomic Pathology
- Cardiology
- IT Infrastructure
- Laboratory
- Patient Care Coordination
- Patient Care Devices
- Quality, Research and Public Health
- Radiology
Last year's IHE North America Connectathon drew nearly 400 individual testing participants from more than 70 organizations.
Announcement of Multiple Ballot Openings for the HL7 September 2010 Ballot Cycle
Several HL7 ballots open today. Please see the announcement below...
HL7 Members,
The PDF document linked to below announces the opening of multiple ballot pools for the September 2010 ballot cycle. The draft standards/documents being balloted are associated with:
Clinical Context Management Specification- Clinical Document Architecture, Release 2
- Electronic Health Records
- Version 2 Messaging
- Version 3 Messaging
- Version 3 Specifications, Infrastructure and Foundation
Important Notes
Ballot Opening and Closing: Most ballots are scheduled to open today. However, please be advised several ballots will open later this week, including the V3 Pharmacy ballots originally scheduled to open today. In addition, three CDA-based ballots are scheduled to open this Friday. Additional announcement will go out when these ballots open. All ballots are scheduled to close on Monday, September 27th, 2010.- Please note that the final V3 ballot download packages (from the V3 Ballot Downloads page) are still being updated and uploaded. It is suggested that reviewers who want to download the full package wait until tomorrow, or until after an update on the Pharmacy ballots have been released, to download the full ballot package.
- Ballot pool signup is available now and will remain open until a week from ballot closing. For this cycle, the signup close date is Monday, September 20th, 2010. This is also the closing date for enrollment in Non-Member Participation in the ballots for this cycle. Instructions detailing Non-Member Participation for non-members are posted in the announcements section of the Ballot Desktop. Ballot Pools are available for sign-up on the Ballot Desktop (http://www.hl7.org/ctl.cfm?action=ballots.home)
If you navigate to the Ballot Desktop and it does not correctly display the ballot pools you have previously signed up for, please click the “September 2010 Ballot Cycle” link in the left-hand navigation pane. This will resolve 90% of users’ issues.
Should you have issues logging in to the Ballot Desktop or signing up for ballot pools, please contact either Don Lloyd or Michael Kingery, HL7 webmaster (see http://www.hl7.org/about/hl7staff.cfm for e-mail addresses).