[This Transcript is Unedited]
Hamilton Crowne Plaza Hotel
1001 14th Street, NW
Washington, DC 20005
Agenda Item: Call to Order, Welcome, Introductions, and Recap of Day One Testimony - Dr. Cohn
DR. COHN: Well good morning, everybody pleased be seated, we’re going to get started here in a minute, have everybody take a breath in our new expanded room and space here, air conditioning is working.
Good morning, I want to call this meeting to order, this is the second day of meetings of the Workgroup on the Nationwide Health Information Network of the National Committee on Vital and Health Statistics. The national committee is the public advisory committee to the U.S. Department of Health and Human Services on national health information policy. I am Simon Cohn, I’m the associate executive director for health information policy for Kaiser Permanente and chair of the committee and this workgroup. I want to welcome committee members, HHS staff, and others here in person, and I want to welcome those listening in on the internet. I also of course want to remind everyone to speak clearly and into the microphone so those on the internet are able to hear.
With that let’s have introductions around the table and around the room. For those on the national committee, and not staff or presenters, I would ask if you have any conflicts of interest on any of the issues coming before us today would you so publicly note in your introduction. I want to begin by observing that I have no conflicts of interest. Mary Jo.
DR. DEERING: Mary Jo Deering from the National Cancer Institute, lead staff to the ad hoc workgroup on the NHIN and lead staff to the permanent Workgroup on the NHII.
MR. HOUSTON: I’m John Houston with University of Pittsburgh Medical Center, I am a member of the committee as well as I guess this workgroup, I have no conflicts.
DR. WARREN: I’m Judy Warren, University of Kansas School of Nursing, member of the committee and member of this workgroup, and have no conflicts.
DR. HUFF: Stan Huff, member of the committee, from Intermountain Health Care and the University of Utah in Salt Lake City. I am a co-chair of HL7 and sometimes that comes up, if there’s discussion of HL7 I will recuse myself from the discussion.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the ad hoc workgroup and liaison to the full committee.
MR. BLAIR: Jeff Blair, member of the committee, director of health informatics from Lovelace Clinic Foundation, I’m not aware of any conflicts.
MS. FISCHETTI: Linda Fischetti, Veterans Health Administration, staff to this workgroup as well as staff to NCVHS NHII and I will follow Dr. Huff’s lead and disclose that I have two elected positions within HL7 so that if HL7 issues come up I will recuse myself.
DR. MON: Don Mon, vice president for practice leadership at the American Health Information Management Association.
MS. UNDERWOOD: Charlene Underwood, director of government and industry relations for Siemens, this morning I’ll be testifying in my role as chair of HIMSS Electronic Health Record Vendor Association, I have no conflicts of interest.
MR. DUBOIS: Jason DuBois, I’m the vice president of government relations for the American Clinical Laboratory Association, and I also have no conflicts.
MR. FERGUSON: Jamie Ferguson, director of health information technology strategy at Kaiser Permanente, I’ll be testifying on behalf of the Electronic Health Records Technical Committee of the Health IT Standards Panel.
MS. AMADIAKAN(?): Margaret Amadiakan, NCVHS contractor.
MS. GREENBERG: Marjorie Greenberg, National Center for Health Statistics, CDC, and executive secretary to the committee.
MR. LOONSK: John Loonsk, Office of the National Coordinator for Health Information Technology.
MR. REYNOLDS: Harry Reynolds, Blue Cross and Blue Shield of North Carolina, member of the full committee and this subcommittee, and no conflicts.
MS. SQUIRE: Marietta Squire, CDC, NCHS, and staff to this workgroup.
MR. BARKER: Robert Barker, interoperability analyst with Next Gen Health Care.
MS. DAVIS: Didi Davis from HIMSS, director of IHE.
MS. JACKSON: Debbie Jackson, National Center for Health Statistics, committee staff.
MS. VIOLA: Allison Viola, AHIMA.
MR. HOLIDAY: Sam Holiday with Accensure(?).
MS. LESH: Kathy Lesh with the Mitre Corporation.
DR. ADAMS: Mark Adams with Booz Allen Hamilton and I’ll be testifying on behalf of the caBIG Project.
MS. RUBELL(?): Jordana(?) Rubell from Hogan and Hartson.
DR. EISENBERG: Floyd Eisenberg with Siemens Medical Solutions Health Services and I will be testifying on behalf of HITSP Biosurveillance Technical Committee.
MR. LEO(?): Regon(?) Leo, senior manager, Ensure Scrips.
MR. JARVIS(?): Charles Jarvis, assistant vice president health care industry and legislative affairs for Next Gen Health Care Information Systems and vice chair of the EHR VA Communications Committee.
MR. DECARLO: Michael Decarlo with the Blue Cross and Blue Shield Association.
DR. COHN: Well thank you all for joining us. I guess even though I’m not going to recuse myself in the spirit of openness I do obviously want to emphasize that I work for Kaiser Permanente as does Jamie Ferguson, one of our presenters later on. Jamie, as I understand you’re representing the HITSP panel today as opposed to Kaiser Permanente --
MR. FERGUSON: That’s correct.
DR. COHN: I also do want to publicly note as I did yesterday that I am advisory member of the HIMSS board and the EHR Vendor Association is actually part of the HIMSS organization, this is a non-voting membership activity, I’m an advisory member but I do just to again publicly disclose that.
Now as we discussed yesterday the activities of this workgroup began at the culmination of the very successful first Nationwide Health Information Network forum sponsored by the Office of the National Coordinator and supported by NCVHS in late June and obviously continue with the hearings both yesterday and today. The NCVHS was asked by the Office of the National Coordinator to review and synthesize the results of the June meeting and by the end of September define a minimal but inclusive set of functional requirements needed for the initial definition of an NHIN and its possible architectural forms.
Obviously this work builds on the contributions of key information stakeholder groups including the Architecture Prototype Consortia, which we heard from yesterday, HITSP which we began to hear from yesterday and we’ll hear more from today, CCHIT, and of course the input of the many stakeholders at the June forum. I again as I said yesterday want to emphasize that our role in all of this is really not to make architectural or policy decisions but to clearly designate common requirements as well as requirements that are specifics to particular architectures that we feel are essential.
Now having said that of course we will come across policy issues I’m sure as we began to yesterday and I think it’s our role rather then to decide them more to note them and advise the Office of the National Coordinator of policy issues that we’ve observed in the process but once again without trying to determine the answer to them. Similarly we will obviously also observe multiple different architectures and indeed some of the functional requirements may relate to that but once again our role is not to make decisions on the various architectures.
So let’s turn to the agenda. Obviously this morning we continue with testimony on the functional requirements. We are asking each presenter to limit their testimony to 15 minutes, and I’ll probably remind everyone from panel to panel on that. This will be strictly enforced and really the main reason for that is so we have time for questions and discussions which of course is really the valuable activities of a hearing such as this.
Our first panel focuses on electronic health records and functional requirements, after the morning break we move to biosurveillance. After the lunch break we will hear from other health information stakeholders and then offer an opportunity for public testimony. Then at the end of today’s session we will spend some time in workgroup discussions discussing next steps and sort of reviewing I think what we heard over the last day and a half and reflecting on that.
Now let me also talk a little bit about steps from today and we’ll talk more about that this afternoon as we begin to tighten this up. I do want to remind everyone both in the room as well as listening in on the internet that we are open for written testimony or comment from anyone, both from our presenters in terms of further written testimony, from anyone in the audience who wants to provide us written testimony, or anyone listening in. We do however ask that these additional written comments come to us by July 31st close of business so we’ll have a chance to incorporate them in our work going forward.
Now our hope is and I think we’ll be deciding this later on today is that we may very well have a draft spreadsheet that we can begin to distribute to both presenters and other interested parties by early to mid August to begin to early input. I think our view is to have this be a very open process and we want to elicit additional input before we begin to finalize anything. So certainly we know who is presenting, we’ll be distributing that to them, if there are others listening in on the internet or here in person we’d obviously want to get your email so we can distribute that when it’s ready.
Now we’ll obviously take some comments in the middle of August, we’re also planning on having an open web call on August 31st from 11:00 a.m. to 3:00 p.m. eastern time to discuss what we hope will at that point be a final draft. From there we move to the full NCVHS meeting where the hopefully what becomes, move from a final draft to a final document will be presented on September 13th and 14th for consideration.
Panel V: Electronic Health Records
With that let’s move into our first panel which once again is on electronic health records. I believe our first presenter is Jason DuBois from the American Clinical Laboratory Association. Jason, thank you.
MR. DUBOIS: Good morning. Dr. Cohn, committee members, thank you for the opportunity to testify today on behalf of the American Clinical Laboratory Association, which represents national, regional and local laboratories. My name is Jason DuBois, vice president of government relations for ACLA, and I appreciate your interest in the NHIN’s use case of lab results and broader electronic health record needs. ACLA members have an extensive history of providing the nation’s hospitals and physicians with leading edge health information technology to streamline the laboratory test requisition process and speed the delivery of test results.
Today I would like to focus on four specific issues that are pertinent both to the NHIN’s use case of lab results as well as to broader electronic health record needs. These are one, clinical data standards for laboratory results reporting and test requisition, two, identity/information or correlation, unique patient identifier, three, the cost to large data providers of servicing a national population, and four, authorization as it relates to the Clinical Laboratory Information Amendments of 1988, or CLIA.
However before delving into these issues I must note that as we discuss the functional requirements that will frame the development of the NHIN part of the difficulty in making recommendations is the relative uncertainty of the architecture for such a system, meaning are data going to be pushed or pulled, will information be centralized or decentralized. The answers to these questions will ultimately determine the framework and in turn determine what specific issues laboratories will encounter in sending and receiving information through the NHIN.
For example, authentication of the requester of data becomes a problem for laboratories if the architecture of the NHIN is such that the information resides with the originator of the data, for example a laboratory, as is the case with the Utah Health Information Network, and if I’m not mistaken I think you heard testimony yesterday from UHIN. In this scenario providers request UHIN to query all providers within the network for any information regarding a patient. Regardless of the architecture that is ultimately established laboratories have several issues with respect to the proposed NHIN functional categories that must be addressed for these efforts to be successful.
First I’d like to address the need for uniform clinical data standards for laboratory test requisition and result reporting and describe an effort currently underway within the laboratory community. The creation and adoption of a national standard for test requisition and results reporting will simplify the use of electronic health records systems. Such a standard will help physician practices reap tangible benefits early in EHR implementation and reduce costs associated with EHR system installation and configuration. In addition a national standard will reduce the cost and effort currently required to implement custom interfaces between independent laboratories, really all laboratories, and ambulatory EHR systems.
Likewise a national standard will also significantly expand the set of ambulatory EHR implementations that include reporting of electronic laboratory results and test requisitions. Finally a national standard will also enhance the utility of electronic laboratory result data by specifying structural and coding standards that enable greater automated processing including decision support, quality measurement, and regional sharing. Ultimately these outcomes will enhance the viability and functionality of the NHIN.
An implementation guide that will serve as the foundation for just such a uniform national standard is the EHR-Lab Interoperability and Connectivity Standards, or ELINCS. Currently managed by the California Healthcare Foundation the ELINCS project represents the concerted efforts of laboratories, IT vendors, government agencies, physician groups and many others. The implementation guide is currently under review with the Health Information Technology Standards Panel. While the California Healthcare Foundation is not a standards development organization efforts are underway to transfer ELINCS to an SDO that is a non-proprietary consensus driven organization. Our association and its members, as well as all of those who participated in the project, have spent a considerable amount of time helping to devise this standard and it is our hope that it will ultimately be relied upon as the means for uniform result reporting and laboratory test requisitions.
I say that because the current version of ELINCS is only on result reporting and while I serve on the steering committee for ELINCS the future is such that we hope to move the test requisition down the line.
In addition ACLA makes the following recommendations regarding interoperability standards:
A particular HL7 version, meaning HL7 version 2.3 or a higher version, should be adopted for use in the NHIN together with an implementation guide for that version.
LOINC should be used in the NHIN once an implementation guide is developed.
The adoption of either SNOMED-CT or ICD-10 to replace ICD-9 will require a massive reprogramming effort but one or the other should be selected for use in the NHIN when the HIPAA transaction and code set standards are revised accordingly.
Furthermore to facilitate widespread participation the NHIN should build upon existing standards that are already commonplace in the industry instead of imposing new standards from the top down. Accordingly whatever standards are adopted should be consistent with the HIPAA transaction and code set standards and should take into account any other standards that are currently being employed in the health care industry.
Another issue which ACLA believes needs to be resolved is that of a patient identification strategy. Obviously the most effective patient identification strategy would be a unique patient identifier. However we recognize that the goal of patient safety through rigorous patient identification must be balanced with privacy concerns so if a unique patient identifier continues to be politically unacceptable at a minimum the NHIN must adopt a robust uniform national algorithm for patient matching using a standard minimum dataset recognizing that no such algorithm is perfect and that many records simply will never match due to patient name changes, nicknames, initials, misspellings, marriages, divorces, and changes of address.
Laboratories face unique challenges in this area because they typically do not see the patient and do not control the data acquisition. Certain data elements, such as patient address, date of birth, or even gender may not be required for certain billing arrangements. Therefore any dataset that is employed should not include data elements that providers such as clinical laboratories do not typically have access to, otherwise the system will only further reduce the odds that records will match. The patient identification function is one of the most basic foundations of the NHIN concept and the difficulties associated with a complete matching system must be resolved before the NHIN infrastructure can be completed.
Cost. While not a specific functional category, and admittedly it is out of scope, cost is certainly an issue that must be considered when developing the functional categories for the NHIN. Laboratories and other large data providers face a potentially costly burden because of the depth and breadth of servicing a national population and the resulting expectation of the availability of data and responsiveness with which data are sent. The requirement of certain functional criteria could translate into tremendous costs for laboratories and other large data providers within the NHIN. Examples abound, however I will list a few of these potential requirements which could translate into direct costs for laboratories.
Creating audit trails and conducting regular risk assessments.
Providing patients with a mechanism to indicate that a visit is confidential and hence only the ordering clinician is to be notified.
Supporting entry and display of content in language specified by user.
Presenting data via a web portal immediately upon availability of result.
If adopted as “standards” within the NHIN these criteria, while well intended, will drive up the costs of transmitting and/or storing data for laboratories and other large data providers such as pharmaceutical or imaging providers.
A final issue ACLA would like to raise before the committee is the NHIN functional category of authorization. Within the category laboratories face two problems, one, their liability for the transmission of laboratory results each time they are delivered to another entity within the NHIN, and two, ensuring that an authenticated requester is authorized to view the data, meaning is this a permitted disclosure and is the extent of the request reasonable.
Pursuant to CLIA when test result information is disclosed by the physician to a regional health information organization the clinical laboratory is still responsible for the content and format of that report. In addition, when an EHR vendor changes the test result report that is provided to the physician the clinical laboratory is still responsible for the content and format of that report in accordance with CLIA requirements. Taking this one step further laboratories would then be responsible for test result report information in the NHIN despite the potential for reports to be modified several times over for each and every manipulation made to them when an EHR vendor modifies the content and for each and every time the content was used, for example primary care visit, office visit to a specialist, hospital admission, nursing home stay, etc. This regulatory burden needs to be addressed in order to facilitate the exchange of electronic health data for treatment purposes.
ACLA has proposals to address both situations. In order to address the issue of EHR vendors modifying lab result report content we propose two potential solutions, one, amend the CLIA interpretive guidelines to clarify that the laboratory must only ensure that the CLIA compliant report is received by either the client or the vendor, or other contractually obligated intermediary, system, or two, seek amendment of the CLIA regulations to clarify that the results may be sent either to the client or to the intermediary.
Second, to address the issue of information shared with other health care providers aside from the ordering physician the clinical laboratory’s responsibility for the test result should end once the result is provided to the ordering physician or other vendor. The interpretive guidelines should make clear that the laboratory is not responsible for subsequent disclosure of test result information made by the physician.
The other issue within the NHIN functional category of authorization presents a particular problem for laboratories given their indirect provider status. Developing a strong authentication and authorization infrastructure is paramount to ensuring the privacy and confidentiality of patients whose information is part of the NHIN. The authorization infrastructure would need to provide an architecture governing the release of protected health information for purposes for which patient authorization is required, for example marketing. This authorization infrastructure would need to accommodate the indirect provider status of clinical laboratories. Without this mechanism, laboratories, in addition to other legitimate entities, would have no way of knowing whether requests for PHI are lawful and if so the extent to which the release of the information is a permitted use. Any authorization infrastructure would need to be integrated so that user credentials could be evaluated against the information being requested and the authorizations associated with the patient.
In conclusion ACLA believes the issues discussed in this statement, namely clinical data standards for lab test requisition and result reporting, a unique patient identifier, the cost to large data providers of servicing a national population, and the need for changes to existing CLIA regulations as well as the creation of an authorization infrastructure are necessary to facilitate the transmission of lab results as well as to address broader electronic health record needs in the NHIN.
The questions being asked today are important to the development of a fully functional NHIN that while providing for the transmission of pertinent patient information for quality care also addresses the security and privacy needs required for any system that aims to encompass the entire nation.
Thank you.
DR. COHN: Jason, thank you very much. What we’ll do is let each panelist present and then we’ll have questions and discussions after.
Our next presenter is Charlene Underwood from the Electronic Health Record Vendor Association.
MS. UNDERWOOD: My name is Charlene Underwood and Chairman Cohn and committee members I appreciate the opportunity to be able to testify before you today on behalf of the HIMSS Electronic Health Record Vendor Association. In the audience we also have two other members of that association, Bob Barker, as well as Charlie Jarvis, who are here to support me in answering any questions that may get to a technical area in terms of the testimony when we have the question and answer period.
In front of you you will find two documents, one is a copy of the presentation and the second is actually the written testimony. I’m going to walk through the presentation but we’ll be able to reference the written testimony in addition to that.
Again my name is Charlene Underwood, I’m director of government and industry affairs for Siemens Medical Solutions and chair of the Electronic Health Record Vendor Association. The HIMSS Electronic Health Record Vendor Association is a trade organization representing leading ambulatory and enterprise electronic health record system vendors that address national efforts to create interoperable EHRs in hospitals and ambulatory care settings. Perhaps more importantly we are advocates for our customers, many thousands of providers who today use our systems with the goal of improving patient care.
Today I’m going to cover these topics, I’m going to give a little bit of background in a very limited way on Electronic Health Record Vendor Association, address key NHIN functional requirements, and propose and share a suggested response to that which we’ve published, and you can find on our website, the EHR interoperability roadmap, as well as suggested phasing of meeting the NHIN requirements, and lastly close with what we view to be the next steps.
The Electronic Health Record Vendor Association is a trade organization that represents 41 leading ambulatory and enterprise electronic health record vendors. We have focused significant efforts since our founding in 2004 in two major areas, in helping found a viable certification process with the goal of helping to reduce the risk of EHR adoption. We also recognize the need and the value of sharing health care information amidst our very diverse systems and we are very committed to empowering patients and providers by sharing patient data accurately and securely among our hospital systems. As you can see by the members here, and actually the members on the next slide, we were created to create a forum of the vendor community to work together where appropriate on topics that effect EHR adoption across the health setting and we truly believe that rapid widespread adoption of EHRs will improve both patient care and the productivity of the health system.
And to that end we see that the need to be able to share data amidst our systems as being one of those key barriers that are really preventing us from achieving the levels of adoption as well as the levels of productivity that are really possible within the industry. So as part of our mission we really looked for the goals that we thought would make, the factors that would make interoperability possible and we recognized a couple of those factors in our planning as we work together toward an interoperability model.
One was to follow a benefits based incremental approach and I think this echoes the fact that we cannot follow a record replace model, we have hundreds of customers who have hundreds of systems, who have significant implementation and systems today and they need to be able to build from where they are and increment things in a benefit oriented way. To do that however we recognize that unless we work together in the vendor community and with other organizations we’re not going to get to the ability to be able to share data in a very disciplined way so that we can really move to a more plug and play type of model in terms of sharing information. So to that we support promoting industry collaboration, the vendors certainly cannot do it alone without a lot of other support from other stakeholders in the industry, as well as we’re very supportive of utilizing industry best practices which I think DiDi will be talking about and we’re supportive of processes like the integrated health enterprise. We advocate for a single set of interoperability standards and we also recognize that there’s going to be levels of sophistication of interoperability standards as we move toward wider spread adoption of sharing electronic health records so we advocate for levels of interoperability as we migrate to increasing sophistication over time and the ability to share information.
So to that end when we stepped back and looked at the diversity of the provider community that we serve and the diversity of systems out there that serve that community we recognize that we had to define some requirements and boundaries within which we want to work in a NHIN environment and I’m going to cover those requirements for you, they’ll be three requirements.
Number one, we advocate for the need to allow the edge system to retain functionality and autonomy. And again this is going to enable health care applications at the edge to be able to meet the workflow of their end users as well as minimize duplication of services that are provided by the core. We believe that utilizing a thin architecture for the core NHIN and its sub-networks will leverage the functionality of the edge systems that are connected to it and is more cost effective then duplicating the edge system functionality within the core.
Secondly whereas in the real world we potentially see value of a common architecture approach to be able to simplify how information is attached the reality and the data shows that there’s a lot of different architectures that may occur within the, that we have to be able to attach to. So we advocate creating an architecture with the flexibility to support centralized or distributed data repositories within the NHIN and its sub-network, and this will help us by minimizing the proliferation of interfaces for different storage schemes as well as recognize that there’s going to be evolution of these architectures from more centralized to decentralized or vice versa architectures over time. So creating the concept of the edge function versus the core where the core can be evolutionary was a key requirement when we put together our proposals.
The third requirement really focused on having a thin NHIN core, if you will being agnostic, and we believe that limiting the core functions of the NHIN will lead to more robust edge systems as well as recognize the diversity of systems that have to attach to the NHIN. And we’re a very strong advocate of supporting diversity at the edges while supporting homogeneity at the center in terms of facilitating the data exchange from edge to edge as well as between edge to core.
So to that end one of the steps that the vendor association took, and this was in response to Dr. Brailer’s RFI at the beginning of 2005, was to look at an incremental approach to achieve a National Health Information Infrastructure. And we created at that point a HIMSS interoperability roadmap with the goal of supporting interoperability, interoperable EHRs by the year 2004. And we also defined it in such a way that the roadmap would be deployed in a phased approach that would deliver incremental benefits that would leverage current technology that’s available now and add new function as it emerged and became viable as well as it was cost effective. This roadmap is based on accepted and tested standards and its organizing principle is empowering patients and delivering care in a patient centric manner --
MR. HOUSTON: Can I ask one quick question by your slide, is the stuff in the blue box section at the bottom intended to be core functionality? The part of your slide where it’s in blue at the bottom, is that core functionality --
MS. UNDERWOOD: Yes, and I’ll get to that. So that end, this is the blue box part of it, the functionality that we see, the edge systems to the core systems is represented in the blue box below and what we did was we took the functionality that you’ve defined, the functionality from the NHIN that you provided us, and we’ve actually mapped that as an attachment to these boxes in part of the, in the written testimony that I gave you, so we took that step to map your functionality into these boxes.
And again, the functionality that we see as the basic functions that are part of the NHIN are information that’s needed to support the processes, identifying patients, providing access, as well as some key functional areas that are generic to support data processing within the NHIN including document sharing dynamic information management and transactions. So this is a pretty agnostic layer that is really independent of what the content is and these are the pieces that are mapped to the NHIN core. And it would be our request that perhaps you could look at writing your functional requirements in the context of these services.
So to that end then, so that’s the functionality at the NHIN level. And I wanted to speak, one of your questions was what was that minimum set of services that you had to provide in the first level and again we would advocate that again clearly the means to identify patients as well as provide access in some level of document sharing is that a minimum going to be a required to be able to support the NHIN as it starts, perhaps some dynamic information management. And we have done the work to map the current use cases coming out of HITSP into these areas and most of them could be handled with the first two boxes and the green and yellow box that you see on the screen so we can share that at an additional level of detail.
As you look at the other component, and again as you think of this, this is kind of the future vision, as all these are deployed this is going to look like our interoperability vision of the future. But the view that the vendors have taken is we will be implementing pieces of this architecture over time so for instance at this level in the EHR level the services that are depicted here, medical summaries, radiology, lab results, are domain specific and these are the pieces that are implemented by each of the vendors at the edge system in a very consistent way. So for instance if we want to share medical summary information the vendors will do that in a consistent way and then we will use a document sharing infrastructure to be able to communicate and share that information with, same for radiology reports, potentially historic lab results in terms of sharing information and that again domain can increase and then you can use the different types of services for the different types of communication that you have to perform.
When we wrote the roadmap we expected that the roadmap would be implemented in phases so the other thing that we did, we looked at the current standards that were available as well as the current content standards that were available and we proposed four levels of implementation that would be built on each other logically over time and would provide incremental value with each step. And we would be starting more simply with the types of functions that are convenience functions that make sharing information easier, that actually if you will take away the paper and actually support some of the productivity issues, two functions that ultimately over time become more supportive of the data that’s captured and enable functions like clinical decision support, sharing knowledge, and doing population based management. And all of those steps are included in our roadmap.
DR. COHN: Charlene, could you go back to that slide, I’m not sure that you actually talked about this one, am I confused --
MS. UNDERWOOD: Did you want me to walk through each of the phases?
DR. COHN: Yes, just to make sure I understand, I apologize --
MR. BLAIR: And Charlene, for my benefit, could you, if there’s a list of functions that you let me know what they are.
MS. UNDERWOOD: Thank you, Jeff, sorry. Phase I of the functions is really the ability to share patient care status information and what this is about is the ability to be able to from an encounter capture that information in a medical summary format and be able to share that amidst our electronic health record systems in a structured form, think of the continuity of care record and share that amidst our systems and we actually demonstrated that at the HIMSS interoperability showcase this year, this is the one that we told Dr. Brailer we were going to do in a year so many of the vendors have stepped up and done that first phase.
The second phase is sharing diagnostic results and therapeutic information and this adds patient created information in emergency summaries plus lab and prescription information and the ability to be able to share that information either via structured documents and/or transactions, so we’re looking at this phase for instance in support of the EHR work that’s being done in the HITSP committee in terms of supporting that. And again what the standard is will resolve out of the HITSP process.
Phase IIIs include advanced clinical support and access function which includes increased access control and notification, exchange of more advanced continuity of care documents, and dynamic queries for medications and allergies with more extensively coded data, so as each phase advances we recognize that the standards for codification are going to be improving and we will be adopting those standards so that we can share and integrate more of the allergy information, the medication information, across those systems and enable that information to be imported into our system, again it’s going to be evolutionary. But at that point then you can start to think about clinical decision support, so first phase is let’s share the information, phase three is start to actually share data semantically.
And the last phase really looks at introducing more work, is called collaborative care quality, active quality reporting and health surveillance, it’s the ability as a byproduct of data capture to be able to generate either performance information relative to surveillance information as well as information relative to performance information and be able to communicate that information via transactions and/or receive notifications back and respond to information that’s provided back with notification of a breakout. Clearly in this phase we could also be looking at supportive clinical trials and other types of research but that phase becomes more advanced in terms of understanding more the data that has to be captured for performance and metric purposes and building that into the workflow, again more invasive into the EHRs such as can be captured as a byproduct of data capture.
So again starting pretty simply, convenience type functions, moving to functions which enable the workflow by providing clinical decision support, as semantic interoperability increases recognizing they’ll be advancement and performance measures that will be captured as part of workflow so that at the end we can be able to inform population management more effectively, so that’s kind of the series.
The good news today is we’re not working with, this is not brand new, as I mentioned a significant number of vendors demonstrated Phase I at the HIMSS interoperability showcase, we’re focusing on introducing advancements in that for the HIMSS interoperability showcase this year. But in addition we also recognize that health care is not contained to the United States, it is global, so this shows a picture of the world and where the concepts of the interoperability roadmap is being used, certainly for instance in Canada it’s being looked at being adopted by CSC and IBM in some of their RHIO structures as well as Denmark, France, so again, it is a global concept that’s being adopted so the principles upon we’re founding are really being tested globally.
Finally one of the key points we want to really bring to the table here is that vendors have been working on interoperability and have invested significant efforts in terms of sharing data within health enterprises as well among ourselves for many years and there’s thousands of years of experience here and we really ask that we leverage the experience of the industry as part of this process.
Secondly, and this is clearly a message from our customers, is we must be pragmatic, we’ve got to take a business oriented approach and make sure that each step of the way. There’s value to the customers who are stretched today to do their job let alone adding new steps into their workflow which could impact them taking care of a patient which is our first priority. We clearly advocate moving toward a single set of standards and private sector initiatives because putting us all on the same page in an organized way is going to get us to our vision of interoperability health care much more effectively then not going in that direction. And lastly we’re fully committed to deliver interoperable EHR components for NHIN demo products to demonstrate what works, and we think those will help us move forward in terms of achieving our vision of interoperability.
So on behalf of the EHR VA Mr. Chairman I really want to express my gratitude for the opportunity to share our perspectives on creating the National Health Information Network. Thank you.
DR. COHN: Charlene, thank you very much. Obviously as I said we’ll take questions and comments after our presenters. Don Mon, you are I believe next, we don’t have copies of your presentation --
DR. MON: There’s not a Power Point presentation, there is a handout --
DR. COHN: So thank you for joining us, I understand you’re representing CCHIT today as opposed to AHIMA.
DR. MON: Yes, I apologize, I forgot to say that in my introduction.
Good morning, Chairman Cohn, members of the committee and fellow participants, my name is Don Mon, vice president for practice leadership at the American Health Information Management Association, an industry liaison for the Certification Commission for Healthcare Information Technology. It is in this latter role that in which I articulate CCHIT’s responses to the questions you’ve posed. Thank you for allowing us this opportunity to provide input on the issues related on the Nationwide Health Information Network.
Please be aware that because of the timing of CCHIT commissioner meetings the response time for this meeting was not sufficient for us to develop a position and take it to the full commission for formal approval, therefore the statements that I will make today represent the initial thinking from CCHIT’s leadership rather then an official position by the full commission.
And also let me preface my remarks by explaining the certification process and the timeframes within the contract that CCHIT has with the Office of the National Coordinator with respect to network components. Per the contract CCHIT will not begin certifying network components before 2008, the third year of its ONC contract. Parenthetically in the first two years CCHIT will certify ambulatory and inpatient systems respectively.
To certify network components in 2008 there are a lot of things that have to be done before certification actually begins, the first is that CCHIT must assemble workgroups comprised of industry experts who volunteer, who apply and volunteer for these workgroups. These workgroups will then develop certification criteria for network components throughout 2007 and then begin testing components for certification in 2008 or beyond. So essentially what happens is that these workgroups through an environmental scan go out to the industry and do as we are doing now, listening to the input that is being gathered from the NHIN forum, going to events or meetings like this to gather that input so that we can put it on our early detection system about what kinds of things might be coming forward for network components.
Getting back to the workgroups, it’s these workgroups who would normally scan the industry and then engage the collaborative projects, for example coordinating certification with the harmonization of standards with HITSP and then also to evaluate the requirements that they have been posed in the questions below. So obviously given the timeframes that I have just laid out these workgroups don’t exist and therefore we don’t have definitive work on the NHIN requirements. However we are able to give you some initial impressions from our staff and leadership of CCHIT with the caution that our input may evolve over time and we may have different input for you once we’ve assembled the workgroups next year.
I’d also like to add that CCHIT is not a standards development organization, we don’t make the standards. The way that the process is supposed to run is that there are standards development organizations that develop the standards, it then gets harmonized through the HITSP process, and then CCHIT takes those kinds of requirements and extracts them and puts them into certification. That doesn’t mean that we’re passive about the functional requirements, for example with the NHIN requirements, as we have found when we developed the ambulatory certification criteria we found that there were certain things within the certification criteria that we then had to go back to HITSP and back to some of the standards development organizations and suggest whether or not they could include those so that we can then follow that chain of it becoming a standard to be harmonized and then certification.
So as to the questions that you’ve posed, the first one was what are the minimum but essential network functional requirements, focusing mostly on the core systems. As there are 1139 functional requirements listed we chose not to comment on individual requirements and so we’d like to frame our remarks in certain domain areas. And these are the barest of minimum requirements, the first one is in security, privacy and confidentiality, CCHIT is hearing very loud and clear from all stakeholders that that is an area of concern within networks in general, whether it’s the NHIN or state level RHIOs or local RHIOs. And when we talk about security, privacy, and confidentiality it is all of those controls for who has access to the record, who has access to the record and what was accessed, and these will be consistent with CCHIT’s security and reliability certification criteria.
So one of the first recommendations that we would have is that there should be an analysis between the NHIN functional requirements and CCHIT’s security and reliability requirements to see where they overlap, we have not had the opportunity to do that just yet but seeing that we have just received these functional requirements in late June from NHIN that’s one of the things that could be done.
The second area is in patient identification, in NHIN environment it will be extremely crucial that patient records are matched correctly before health information is exchanged and that is even more crucial as we’ve been hearing as the NHIN discussions have evolved about how PHRs are playing a role in the NHIN. And so if individual consumers are permitted to access the NHIN through their PHR then patient matching is going to be all that much more important.
And then the third area can be summarized as completeness of the record but it was much more well articulated by Jason DuBois, these are issues such as what data were sent and whether there were subsequent updates to that health information by the data source.
The above are the most essential requirements, we certainly recognize that there are many more domains that are important to the operations of the NHIN but as we mentioned we felt that these were the bare essentials.
In terms of the specific edge systems, what functions would be minimum but essential, here again we would suggest an analysis that compares the functional requirements of the NHIN to CCHIT’s functional requirements an we reviewed the list of 1139 functions, we did see some things there that mentioned that you know lab data should be sent and other data should be sent and we have those similar kinds of functions within the certification criteria. Obviously the two should be in sync such that it may be possible that because CCHIT is also taking a minimal approach and then an incremental approach that there may be some functions within the NHIN set of functions that aren’t certified and there may be some things that are in the CCHIT requirements that aren’t in the NHIN functions. But it would be worthwhile to compare those two sets of functional requirements and see if it doesn’t constrain one or the other.
We applaud the workgroup that put together the Power Point slides, we think that the first, the slide that we were distributed showed the architecture and then all of the domains on the second slide. In terms of all of those points I think that all of those domains that were listed on the second slide were spot on, the one that we don’t question but don’t think is necessarily a minimum but essential is the persistence of data when it is construed as storing data in a central repository, clinical data in a central repository as there are some RHIOs that are taking an approach in which there is no storage of that clinical data.
And then lastly the question as to whether or not there are other standards that were not identified through the HITSP use cases, we think that HITSP has done very well to review the myriad standards that are relevant to the respective use cases and at this time we do not have other standards to bring forward for consideration. Our review of the 1139 functional requirements showed that there was nothing unusual with the functional requirements except for one thing that is piquing our interest and that again surrounds the involvement of the PHR inside the NHIN. The PHR involvement in the NHIN just introduces another level of complexity to the NHIN and we found that in line, specifically in line 324 it mentioned, it used the phrase fully qualified PHRs, it’s not clear what is meant by fully qualified PHRs and what is done to qualify them. Does that mean a fully qualified PHR is one that is certified and if so that means that CCHIT must now attend to something like that, and that’s an area where we see that by looking at other projects like the NHIN project we see something that puts something on our radar screen.
So thank you very much for allowing us to provide this input and we’ll be glad to take any questions that you have.
DR. COHN: Don, thank you very much. I do want to remind everybody before Jamie starts to put your cell phones on mute since I’m hearing little ringing of various sorts, one of our members just left with that, but if you can put it on quiet or vibrate or whatever for your cell phones.
Now our last presenter is Jamie Ferguson, obviously thank you for coming all the way from California. I do want to just relate to you a conversation we had yesterday knowing that Elaine Blechman has already presented some of the information here. It was unclear to us whether or not there was an intent by both you as well as Floyd to both review the early parts of these presentations on the background of HITSP and I guess I was hoping that that was not going to be --
MR. FERGUSON: My intention is to skip straight to the testimony from our committee and then in the question period I can take and answer any questions on HITSP in our process and overall status.
DR. COHN: We appreciate that, thank you very much.
MR. FERGUSON: My name is Jamie Ferguson, I’m here as co-chair of the Electronic Health Record’s Technical Committee of HITSP, or EHRTC. First I want to thank you for giving our committee the opportunity to comment here. I’d like to start on page eight of the written testimony and take any questions about HITSP later, also there were some Power Point slides that I believe were distributed to the committee yesterday, there are also copies over on the table, I’ll be referring to those but I will not be presenting those on the screen.
The Electronic Health Record’s Technical Committee of HITSP has conducted a series of open sessions to create HITSP’s work products and deliverables related to the initial EHR use case. The committee currently has 89 organizational members representing all sectors of health care in the United States and our committee meetings typically include lively debate on a wide variety of related issues.
Since the first NHIN forum on June 28th and 29th the NHIN functional requirements and the relationship of the NHIN framework and NHIN concepts to the standards and implementation considerations for a use case have occupied some of our time in these open sessions although it should be mentioned that those discussions have not been the main body of work for the committee. This testimony attempts to represent those discussions faithfully, completely, and concisely.
As context for the following points I’d like to refer to the three slides on pages 24 through 26 of the Power Point presentation. These slides represent the functional flow diagram for the EHR laboratory results use case that was published by HITSP in the Technical Committee presentation to the HITSP panel, document HITSP 06 number 95 on June 14th. The slides also represent an example of the adaptation of these functional elements into interoperability specifications for the scenario of sending an electronic lab result to authorize providers of care for use in clinical care. The document HITSP 06 number 95 is an appendix attachment and I’ll now explain the diagrams in those slides.
As described in the slides EHR lab use case can be viewed in two primary scenarios, in the first scenario a releasable electronic lab result is sent to the ordering clinician, to authorize providers of care and to a data repository. Interoperability in this scenario a set of functional interactions must occur that requires standard laboratory terminologies and message formats, and that communicate characteristic message content.
In the second scenario authorized providers of care may query either a data repository or a record locator service to retrieve lab results or result summaries. It should be possible to enter the queries from within an existing EHR system or through an independent web application without an EHR system. For interoperability in this second scenario a further set of functional interactions are performed such as those to create and retrieve a structured document containing the lab results. All of these interactions involve multiple actors and all the actors described in this work generally are agreed to be edge systems for purposes of the NHIN. If these actors are unspecified edge systems and a wide variety of implementation architectures is enabled in which any of these actors may be combined in edge system entities in practically limitless ways.
From the perspective of the HITSP standards specification for linking the NHIN and the current EHR use case functional services of the NHIN core should be restricted to a minimal set of transport services. In a manner in the electronic realm it is analogous to a commercial package delivery service in the paper realm, or if the NHIN should deliver electronic packages to authorized receivers in a reliable and secure manner. And this should be done without opening the packages or performing any additional services related to their contents or their containers. Again using this analogy a set of NHIN core functional services related to transport would include verification of the address of the recipient, authentication of the identity of the recipient, or giving the sender an acknowledgement of receipt. Related security policies and security profiles may require specification by the NHIN.
Specific standards for these NHIN transport related services should be determined by HITSP in consultation with appropriate designated parties. Standards and related specifications determined by HITSP for most or all other functions required by the use case generally are used in functional interactions between health care systems and health care entities. The inclusion of standards for these additional functional services in the core of the NHIN would limit architectural choices, it would have the effect of dictating selected implementation options in some cases and it would limit commercial variation by requiring the bundling of some optional functional services with mandatory functional services in EHR systems.
An example of these effects is found in terminology services which is described in the HITSP standard solution to the EHR use case. For interoperability to be achieved a standardized set of terminologies must be used. There are many ways of achieving this end and a wide variety of solutions can be found in the commercial systems that are currently marketed to edge systems. In this example the inclusion of standards for functional terminology services in the core functions of the NHIN can severely limit market choices and limit related implementation alternatives.
As in the functional diagrams HITSP interoperability specifications for this use case will cover a variety of functional services in addition to those related to transport. Among others some functional services for electronic clinical messages and clinical documents are ones to create, address, send and receive them, and to execute rules which perform operations on their contents and their formats. Without favoring any architectural choices for edge systems it still can be stated that multiple hierarchical tiers, or layers of edge systems, should be agreed to contain and perform the additional functional services. Specifying a multiple number of edge system tiers or layers would enable a wide variety of architectural approaches to be implemented because these additional services could potentially be placed in any tier or layer in any configuration and it could enable architectural variation to coexist more peacefully. This would be true particularly if their definition promotes a common set of interoperable interaction specifications between edge layers for the additional functional services.
HITSP should select relevant standards and develop interoperability specifications for these interactions when the core services are defined. Architectural neutrality would be promoted further if it were clear that any edge tier or layer could interact with the core NHIN transport services under specified conditions. An example of these edge system layers can be found in states in which a state regional health information organization, or RHIO, operates in conjunction with both regional and local RHIOs as well as multi-state delivery systems and networked communities of interest. In this example it would be helpful to have a set of conditions and specifications for interactions of these tiers or layers of edge systems with the NHIN core functional services.
A categorization of these specifications for geographic and non-geographic edge systems could simultaneously allow for states to oversee health information exchange programs within their state and for non-geographic networks or communities of interest to common specifications for interactions with NHIN core services. It should be reemphasized that any such definitions of multiple tiers or layers of edge systems need not play any limit or constraint on architectural options. To enable standardized interactions of edge system with the NHIN core HITSP should be engaged to determine the standards and interoperability specifications as soon as policies are proposed that specify any conditions or boundaries for edge system interactions with the NHIN.
In summary the HITSP EHR Technical Committee believes that the functional services of the NHIN core should be limited to reliable and secure transport of unaltered electronic messages and electronic clinical documents.
The Technical Committee would like to thank you for the opportunity to comment here.
DR. COHN: Well Jamie, thank you very much, I want to thank all the presenters for what I think has been some very interesting testimony. Now are there questions from the workgroup? Harry?
MR. REYNOLDS: Thanks to everyone, nice job. I had a kind of quick question for each one of you. Jason as you presented you focused a lot on regulations, I didn’t seem to pull out of there what you thought the base requirements were.
MR. DUBOIS: Well one of the problems with the exchange of information today electronically is that laboratories have to abide by the Clinical Laboratory Improvement Amendments in CLIA and those do all, they regulate quality control, quality assurance, and among them is that the requirement that a result report is received by the ordering clinician and that the report, the laboratory under the regulations and under the law are required to ensure the delivery of the result and that it appears according to different specifications under CLIA, that the management director of the laboratory sign off on certain types of laboratory test results and there are other requirements under CLIA. Well one of the problems with the way that that information is shared today, at least electronically, and know that when CLIA was passed into law and regulations were written out that I don’t think there was a lot of thought given to the exchange of laboratory result information electronically.
With that said I think that some of the problems are that vendors who are serving the physicians or hospitals will actually change the perspective or the view of that result and in some instances laboratories can be considered liable for that despite the fact that it’s the vendor and not the laboratory that’s changing the view of the results, so they might take down whether it’s the physician that signed off, and they do that because it’s the physician or the hospital that wants it most often, they want to see, they want to see the result stripped down so it’s just okay, show me what the glucose number is and I don’t care what the doctor, who signed off on it or the full report on what the AP of the breast biopsy is, malignant or benign, that’s all I want to know.
So with that said laboratories can be considered liable for that information once its changed and furthermore also a concern for many of our members is that not only does it change there but once its shared with, let’s say it’s a RHIO example in Indiana, that they’re required to ensure the result of that lab data to each and every person that sees a result besides the ordering physician.
I don’t know if I answered your question --
MR. REYNOLDS: No, you reiterated that you guys aren’t ready to go there --
MR. DUBOIS: We want to go there --
MR. REYNOLDS: And that your relationship tends to be more between the lab and the practicing physician.
MR. DUBOIS: And we want to, we’re trying to, that’s why we have suggestions here in the testimony and we’re also working with the Office of the National Coordinator and CMS to try and fix these, what we see as impediments to the exchange of lab result information.
MR. REYNOLDS: Charlene, quickly, on profiling, what do you mean by that?
MS. UNDERWOOD: The use of a process such as integrating the health enterprise where we have actually defined within a profile how we’re going to be using a specific standard, so it’s the profiling --
MR. REYNOLDS: So it’s business rules between --
MS. UNDERWOOD: Business rules, we’re narrowing down those processes so that they’re common among vendors in terms of how we implement.
MR. REYNOLDS: And some of your focus was on interoperability between edge to edge and as an industry we have tended the more we become edge to edge and one to one things haven’t gone quite as well in general, I mean whether it’s the payers to the providers and edges to edges and vendors to vendors, it’s made it more complicated, so I was interested in, you mentioned the things that you thought could be useful in the center --
MS. UNDERWOOD: In the center, and I think that resonated with Jim’s testimony, that we see, because of the variability of architectures, capabilities, workflow needs to be maintained at the edge where the centers needs to be this common set of transport services, so I think that’s really the same message. And what we’ve seen and actually as we’ve looked at the HIPAA transaction models there’s been, where there’s still variability and a lot of content diversity at the edge over time it does improve and become increasingly standardized so that it’s easier to do that exchange. So it is a process that will evolve as opposed to something that we’ll start out with, but it doesn’t mean not to start and we think we should start.
MR. REYNOLDS: Don, bears to the minimum, is that a disclaimer or is that a base set of requirements?
DR. MON: That was a disclaimer.
MR. REYNOLDS: Just making sure we understand. Those were my questions, thanks.
DR. COHN: I guess I had one and I know Jeff has a couple of questions. I was actually trying to reconcile and trying to figure out what HITSP, what you’re recommending, Jason, I was having some trouble understanding, I recognize the complexity of CLIA and certainly there’s a fair amount of complexity there. I was just trying to figure out whether or not you’re supportive of what Jamie was saying around HITSP in relationship to how things ought to be transported and what ought to be happening, or do you have other views on this? Do you remember what he said?
MR. DUBOIS: To a certain extent --
DR. COHN: Let me just read it to you, it says in summary HITSP EHRTC believes that the functional services of the NHIN core should be limited to reliable and secure transport of unaltered electronic messages and electronic documents. So I’m just, I mean is that something that --
MR. DUBOIS: I don’t think they’re out of sync with one another, I think that we’re just, with the CLIA regulations we’re just trying to, we are trying to facilitate that exchange and know that no big companies like Quest Diagnostics or Lab Core, who are our members, are going to be doing this, unlike a lot of other laboratory providers that do it on a regional scale, you’re talking about companies who much like the NHIN setup already exchange this information nationally. So to a certain extent some laboratories are already there but we’re just, the concern is just making sure that laboratories aren’t responsible for the final report each and every time that that data is provided to others within the NHIN infrastructure.
DR. COHN: It looks like both Charlene and Jamie have further comments.
MS. UNDERWOOD: Again, I’m going to be very practical, if I were to get a copy, let’s just say they sent it out in a document format then when I would receive that in my system if I would see something in that result that would be relevant to some other information that I stored in my system I might want to present that result in the context of some other clinical information. That’s where the restraint in terms of me having to present it as it was sent to me so that by the CLIA regulation constrains, could potentially constrain how I interpret that and advance that knowledge to my end users. Is that kind of, so I would like it and I could take it in that same way but once I get it then I want to do something with it that makes it more useful for the person that I’m serving.
MR. DUBOIS: And one of the changes that we’re requesting is that when the vendor does receive it that that would be considered receipt of the result report and that it’s okay, they’re trying to facilitate the way that the physician will see it but as it stands now we’re still on the hook for the way that the laboratory result is viewed by the physician despite the fact that it is being manipulated by an intermediary.
MR. FERGUSON: I’d just like to note that in order to meet the current CLIA regulations and without changing that policy we’ve been very careful in our work in the HITSP Technical Committee to make note of standards for these electronic messages and particularly the lab results documents that can uniquely identify the custodian of the document being the source lab and so that’s complicated, for example in the case where the lab that receives the order then sends it out to a reference lab and it’s actually the reference lab that has to be identified on the document through the complete chain. So what we’re doing today is we’re making sure that the standards that we use for solving this use case can meet the current regulation and then if the regulation has changed then we would perhaps have to change the standards to meet the new regulation.
DR. COHN: Jeff?
MR. BLAIR: I’ve kind of been saving this question because it is a difficult one but I think that this panel is probably more capable of coming up with constructive ideas to begin to address, an approach, if not a definitive answer then an approach or some suggestions that could help us to identify the minimum set of functions for the NHIN. If you had a chance to listen yesterday there’s a chorus, everyone indicating that we’d like to have the NHIN be as thin as possible. On the other hand one of the other things to balance that off is that it avoid rip and replace, in other words it has to be flexible. And this panel I think has individuals that have dealt with the fact that you go from version to version to version of standards and the NHIN is going to have to deal with this problem so that it could support more then one version of message format standard and over time different systems that might have not only different coding systems but different versions of the coding systems.
So I’d love to hear any thoughts you might have as to how the NHIN could remain as thin as possible but still be flexible to accommodate the fact that different EHR systems, e-prescribing systems, clinical labs, might either have different message versions that they support or different coding systems or different versions of them. Words of wisdom, how can you help us?
MR. FERGUSON: We’ve actually had I think quite a bit of discussion on this in the EHR Technical Committee and I think to summarize our discussions I would say that the answer is to minimize the number of standards that are acceptable and allow the market and allow the edge systems to determine how they transform their clinical content and their messages and documents and their terminologies into those target formats and target code sets.
MR. BLAIR: Do I hear you saying that the edge systems must be responsible for conforming to a single standard of the NHIN?
MR. FERGUSON: In general, yes --
MR. BLAIR: And what happens if over time the NHIN decides to change a level or a version?
MR. FERGUSON: I think our view is that we want to minimize the number of different, and I’ll say for example terminology subsets, so that we would want to minimize the number of SNOMED or LOINC subsets in the case of the lab results that are acceptable as the standard set for interoperability and so today in HITSP we’re in the process of selecting and finalizing the first set of standards so we recognize that those things will change over time, that a maintenance process will be required but I don’t think there’s a, we don’t have a pat answer on how to manage that maintenance and upgrade process other then to minimize the number of standards that are acceptable.
DR. COHN: Charlene, you look like you had a comment on this one.
MS. UNDERWOOD: I just wanted to reinforce some of those principles and Bob, if you want to add, because I know you’ve lived this for a long time, any points to that that would be fine. But I think I want to reinforce again the focus to fewer standards, more harmonized standards, so for instance when we look across the three use cases that are active now, biosurveillance and the lab as well as the consumer empowerment and I look at it and I see redundancy of the data across those three different efforts, I’m sitting there praying that I don’t want one standard for each one, I want one standard that will enable me to respond to those use cases dependent on what my users needs are and I could just populate it accordingly.
So I think the focus needs to be as we drive towards standards in the future, data driven standards as opposed to specific transactions for every single scenario that we’re going to run into, but I think that’s really saying the same thing. Likewise at the edge I think there has to be leadership on the part of the nation to direct us toward more single sets of codification standards and I think those pieces have to come together.
So that is where policy and process will actually make this happen because at the edge today there’s incredible variation in data content and quality by every single one of our users and to do that mapping is going to be at the detail level and they will not move until there’s some substantiation that it’s worth making that move, trust me. So those things I think are important in terms of the leadership.
Bob, did you want to add another point?
MR. BARKER: I’m Robert Barker with the EHR VA and what Jamie was saying earlier was number one was to reduce the number of standards that are out there because from a vendor, and I’ll give a specific case, there are two competing SDOs, ASTM and HL7, in different areas, one is the medical summary exchange which is the number one on the roadmap we’ve achieved and I have two sets of developers, one that develops in one standard, one that develops for the other, both of them are doing the same thing. So when you get into your comment was how do you handle the changing versions let alone multiple standards to be used, that’s what we have now is multiple standards and multiple versions of each of these standards and if we can reduce them to at least have one standard that has different versions we’ve simplified the process, we’re using less resources to handle multiple standards and more toward the content and the ability to use the information in a clinical setting, so to reduce the number of standards is the first thing that we have to do.
DR. COHN: Mary Jo was next on the queue, I also have a follow-up on this one.
DR. DEERING: Thank you and actually, Jamie, this is for you and I believe it’s just an editorial clarification of your written testimony, on the bottom of page nine it gets exactly I think at what was just said and therefore I’m wondering, there’s a sentence there that says the inclusion of standards for these additional functional services in the core of the NHIN would limit architectural choices. Surely you don’t mean the inclusion, you just mean the inclusion of these additional functional services in the NHIN --
MR. FERGUSON: That’s correct --
DR. DEERING: So I think that you might want to go in and strike out, we do want in fact standards --
MR. FERGUSON: Thank you for catching that error.
DR. DEERING: That’s the opposite of what you want, I just wanted to as a former, spot a typo at a thousand yards.
Anyway, I had a clarification for Don and it’s a process clarification that you may not be able to answer. In a couple of these instances you suggested that once you’ve looked at CCHIT’s security and reliability certification criteria and other, maybe it is just that single document, and compare it for overlap to the functional requirements, you left it out there as if one should and I guess my question to you is as part of your process over time would that have been an exercise that you intended to engage in?
DR. MON: The short answer here, Mary Jo, is yes, having received the functional requirements in late June when they were published and distributed at the NHIN forum we just didn’t have the opportunity to do that between here and then but then as soon as we saw the format and the content of the functional requirements we saw that there may be some overlap. And so what we’re suggesting is that either, really within CCHIT we’ll take that on to review that but I think it will probably be better served, we just haven’t made the connection yet to work with somebody within the NHIN project and do this as a collaborative exercise and that’s probably the better approach to do that. However that hasn’t been fully discussed within our staff and so that I was a little vague on that, I apologize.
DR. COHN: Can I ask a follow-up question and John you’re obviously next in queue here. But just to follow-up on what Jeff was asking a little bit to make sure I understand and I think, I’m actually just struggling a little bit as we talk about these obviously standards and version changes and obviously terminology changes and all of this, and the concept that we have these unaltered packages that are going to be going through the NHIN and I’m just trying to figure out who’s responsible for what where because it really does begin to speak of functional requirements. I guess if I think of an unaltered package I’m expecting that somehow there’s sort of minimal standards around the package that somehow defines it, routes it, transports it, edifies it as secure and whatever with the need at sort of the beginning and the end people to sort of understand what it is.
Now when you talk about all this, and Charlene you talk about standards and making sure that everybody is on the right standard at the right moment and I’m of course thinking back in the old days of ICD changes, CPT changes and updates and all of this stuff. Are you, and I’m looking at you, Charlene on this one, you weren’t in any way describing filtering or standards that are part of core functionality to make sure that all the standards are implemented inside the package at the point that something is shot through the NHIN, or are you?
MS. UNDERWOOD: No, I think the intelligence in terms of what’s sent and what’s received really has to be managed at the edge so we need to know in the package what it is, how I accept that will be a function of how intelligent I am at that point in time. So for instance in the use of the medical summary status standard it’s got the flexibility for me to just take the document and look at it or interpret the data, and/or interpret the data, but if not too smart I’ll just take the documents so the intelligence of, the standards are now advancing so that they’ve got some levels within them that make them more, my ability to imbed them more evolutionary so I can depending on how intelligent I am. But the intelligence in terms of how to send them needs to be at the edge as well as how to import them needs to be at the edge. And then as the edge becomes smarter in terms of storing things in a consistent way we’ll be able to send things for semantically, accurately, across that transport. So those edges are going to get smarter and more consistent so that the transport layer in between which stays common, the data sharing will evolve overt time.
DR. COHN: Okay, just to make sure I understand because I think you’re agreeing with what I’m sort of thinking here is that, obviously there’s the secure layer, you need to address and understand what the address is and some other pieces in this wrapper but it’s really, and that’s the responsibility in your view of the NHIN and it’s really sort of the edge system that sort of dings, the contents of this are gibberish and sending them back to the other edge system as opposed to there being some sort of a quality review or screen at the NHIN at the beginning saying you can’t even send this, this is not the right code set or standard or whatever for the moment, except for sort of minimal surrounding sort of package things. Is that, am I getting that right?
MR. FERGUSON: That’s exactly right, thank you.
DR. COHN: Okay, thank you. John Paul?
MR. HOUSTON: I had a brief question for Don. You indicated that completeness of the record was one of the three minimum but essential domains you thought needed to be worked, I mean was one of the three minimum but essential domains. And I guess one of the concerns I guess I have is completeness in my mind really is a utopia, I don’t think we’re ever going to have complete information, or there’s going to be a high probability that when you go out and use NHIN to get information you’re not going to get complete information but rather I think it’s probably more likely that you need to know what information you do have versus maybe what holes may exist in terms of where information didn’t come from and maybe where it was expected. What’s your thoughts in general on completeness of the record as well as maybe some of the ways to address that?
DR. MON: I perhaps used that phrase a little bit too glibly because I think what you just described is the latter, in your latter statements, was what we were shooting for and it basically corresponds to what Jason was suggesting as well. We agree that sending health information over the NHIN or even if it’s just a point to point exchange that you may never get the complete record. But what is important is to know what you got and that what I sent you is all I’m going to send you and that’s all I have to send you, and so having that kind of indication is what is useful at the NHIN level.
Is that a little clearer --
MR. HOUSTON: I just wanted to make sure I understood that, that’s clearer, thank you.
DR. COHN: Other questions or comments from the committee? Okay, well I want to thank all of you for what I think has been a very interesting and useful panel, so with that we are going to take a 15 minute break, we will come back at five minutes to 10:00, actually five minutes to 11:00, and we’ll continue on.
[Brief break.]
DR. COHN: We’re going to get started again if we can, our next panel is focused on biosurveillance issues and functional requirements and we’re very pleased to have three presenters, our first is Lawrence Hanrahan who’s from the Association of State and Territorial Public Health Organizations, and obviously I want to thank you for joining us. Our second presenter will be Tim Morris from CDC and then we finish up with Floyd Eisenberg and obviously thank you from HITSP focused on biosurveillance use cases. So obviously we’re pleased to have the three of you here, Lawrence I think you’re going to be leading off so please.
DR. HANRAHAN: Well good morning, everyone, I want to begin by thanking the committee members for inviting ASTHO to provide a public health perspective on what technical functions and services public health would need from a Nationwide Health Information Network.
My name is Larry Hanrahan and I am director of public health informatics for the Wisconsin Department of Health and Family Services in the Division of Public Health. I’m here today to testify on behalf of the Association of State and Territorial Health Officials, I serve on ASTHOs Public Health Informatics Policy Committee whose mission is to provide state based leadership and policy recommendations to strengthen the ability of ASTHO members, the state health officials, and partners to use informatics in making key public health decisions.
Let me begin by going into a quick background into what services public health provides in order to give you a better idea of what we will need from the NHIN.
Public health is not just field agents swooping down in and after an anthrax attack or the reporting of infectious disease agents like HIV or E. coli. Public health is prevention, protection, promotion, response, and services. Public health agencies use data to identify the most pressing health needs so that the appropriate services or policy interventions can be made to improve the nation’s health.
Many of you are well aware of the ten essential public health services and I won’t go through them all today, however, I would like to stress that these must be all kept in mind when we talk about what public health needs from an NHIN.
So in terms of public health services that can benefit from NHIN and what services they would need let’s start with the clinical services that public health provides to the millions of patients each year. Public health provides clinical care just like any other care delivery organization, we run hospitals and clinics, we have laboratories and pharmacies, and therefore these public health services would need for NHIN to provide the same functional requirements and services to them as they would to any other care delivery organization.
Public health however also provides non-clinical services. These can be broken down into routine and emergency with routine encompassing the reporting of notifiable diseases as well as surveillance of non-notifiable diseases and conditions such as injury and new born screening, and systems that we have even in the title of your committee like vital statistics. Emergency services encompass the surveillance and response to natural and manmade events such as hurricanes or the release of bioterrorism agents.
With these services in mind here are the critical functions and services that public health would need from NHIN.
Auditing and logging, in terms of a core NHIN function auditing and logging would be necessary to keep track of which edge systems, whether it be public health agencies, clinical providers, laboratories, etc., are connecting and disconnecting into the system.
Additionally, any edge system that is pushing or pulling information to another system needs to keep a record of what was sent, when, and to whom as well as records on what information has been received.
Authentication and authorization, many of the proposed functional requirements identify the need to authenticate and authorize all public health agencies that would need to connect to NHIN and in previous testimony there has been mention of an edge system registry as a core function. We completely agree with this and feel that anyone who will be adding, viewing, or editing data in the system will need to be authenticated and authorized registered users in order to ensure legitimacy of the health information. The data analysis that public health provides back to the clinical sector is only as good as the data that we receive, therefore authorization and authentication of users is a critical component of the system.
The function of the core system would be to authenticate and authorize each edge system that is requesting to connect to the NHIN.
However it would be a function of the edge system, for example the public health agency, to oversee the authentication and authorization of specific individuals within the agency that would have access, and at what specific level of granularity, to the NHIN.
Data access and update, public health is going to need to have access to the data on multiple levels. For example in order to use NHIN to enhance the disease reporting system we currently have public health is going to have to have access to identifiable data in order to ensure proper follow-up. Likewise in order to use NHIN for public health surveillance we will need to have access to anonymized data which if need be can be re-identified for follow-up.
Likewise different public health agencies will need access to different health information depending on geographical and jurisdictional responsibility. Role based access control that is flexible and scalable will be necessary in order to manage multiple users with multiple access privileges. We see establishing a role based access control as a core function.
Data mapping and translation, we cannot emphasize enough the need for the use of common terminology or the capability of mapping in a standardized format in order to ensure that multiple edge users mean the same thing when they use the same word.
Data quality and data integrity, data quality and integrity should be primarily a function of the edge system, however there can be a role for the core as a backup to the system to ensure that data degradation doesn’t occur in transit.
Data push and pull, data retrieval and transmission capabilities would be an essential element for public health in utilizing NHIN. A bi-directional data flow with public health edge systems and other edge systems will be beneficial for all NHIN users. When following up with notifiable disease submissions public health will inevitably need to make requests for additional information from the submitting care delivery organizations. For early detection or other biosurveillance purposes public health would need to access anonymized aggregated data that can be queried and will give public health officials real time illness data.
Public health also wants to give back into this system and one of the ways we envision giving back is to provide data to other edge users that would be useful, if not critical, in the treatment of patients. For example we could give feedback on the patterns of antibiotic or antiviral resistance to the medical community, we can give population health data on the screening completeness for environmental conditions like detection of lead elevations in our children, look at the geographic variation in stage at diagnosis for cancer and give that back to practitioners, and also give feedback on the course and spread of outbreaks.
We spend a lot of time collecting data and often adjust for the fact that it represents a small sample from the population. Having access to a large set of population data will allow us to prevent disease and disability, instead of just measuring it. In turn we can provide information as a service back out to the clinicians in a timely manner so that they can make informed decisions about a patient’s treatment or prevention measures.
Identify and information correlation, this is something that’s really key to us, being able to correlate information from multiple entities for one patient is necessary for information that is shared with public health. In order to effectively measure incidence and prevalence all the data for a single case of disease is linked to ensure that one case of shigellosis is counted only once and not multiple times because there was information indicating a case by the ER care delivery organization, the personal physician care delivery organization, the hospital laboratory, the private laboratory, and even the state public health testing laboratories.
Likewise if additional information on a patient is entered into any one of the multiple edge systems, including any public health follow-up, there needs to be a way to link that information with all the other information on that case and to that specific patient.
Record location, record location as a core function would be to provide assistance to the edge systems in locating records.
And finally transient data, as a core function transient data within the core would be for the purpose of delivering the information from one edge system to another.
So that’s our 15 minutes of fame, I hope we get a shot at a little bit more and I know we will, I see many friendly faces and colleagues here at the table, it is an honor for us to be here.
But in conclusion I would like to state that public health offers many services that will benefit from the bi-directional information flow from the NHIN ultimately improving public health services and clinical care. As the NHIN comes to fruition public health requirements should be incorporated in all aspects of the NHIN not just biosurveillance. ASTHO stands ready to fully participate in these efforts.
And I thank you again for this opportunity to present this testimony to the committee.
DR. COHN: Lawrence, thank you very much. Now we have copies of your overhead, I don’t think we have actually a copy of your testimony, is that something we can --
DR. HANRAHAN: We’re going to be sending that to you.
DR. COHN: Okay, great, we appreciate that very much.
Our next presenter is Tim Morris, Tim as I understand you’re division director from Division of Shared Services from National Center for Public Health Informatics. So obviously thank you very much for joining us representing CDC in these conversations. Please.
MR. MORRIS: Thank you for the introduction and thank you for the opportunity to provide testimony today. What I’m going to cover is the linkages between Public Health Information Network, or PHIN, and the Nationwide Health Information Network, or the NHIN as we’ve heard many presentation today. As was stated my name is Tim Morris, I’m the director of the Division of Informatics Shared Services in the Center for Public Health Informatics at CDC, I’ve been involved in work directly related to the Public Health Information Network since its inception around 2002 and have been project lead on several projects related to PHIN implementation.
Today I’m going to talk about the PHIN purpose, some functions and components and show how they relate both directly and indirectly to the biosurveillance use case and the NHIN functional categories and core components. I will also show how data and information from both traditional and non-traditional public health partners can be combined with data from the clinical sector through connection of PHIN and NHIN to provide a rich source of information for both public health and clinical sectors.
So again to cover overview of the PHIN purpose, I won’t go into too much detail but the purpose is to improve the capacity of public health to use and exchange information electronically by promoting the use of standards, technical specification, some of the priority functions, workforce competencies, collaboration and data sharing, and strengthening, which is a key, strengthening the use and exchange to be robust and flexible enough in routine times so that it can accommodate an emergency in scale.
When we look at PHIN its been categorized in a few different ways in the past as it has evolved, most recently the PHIN preparedness requirements defined functional areas for systems related to emergency preparedness and response and specific specifications for interoperability amongst these systems. Today I’m going to provide another categorization of functional areas that are a big broader to include public health monitoring, public health intervention, prevention, communications and alerting, and then touch on some of the common services and components which really are the connection between the Public Health Information Network and the NHIN.
Public health monitoring, I won’t go into too much detail on these but again inside of this is what a lot of the biosurveillance use case is about as some of the early event detection, situational awareness, but then you get on to things with notifiable condition reporting, environmental health monitoring, and many other types of monitoring and surveillance throughout public health.
Public health intervention is pretty much exactly as it states, functions include public health investigation and response, environmental assessments, outbreak management, some of the resource utilization again related to response and directly related to the biosurveillance use case, inventory allocation, and then response management and follow-up.
Public health communications is a bit more diffuse but certainly there are some concrete things here with health alerts, decision support, secure communications and collaboration as well as public communications that would be targeted at specific audiences while not being extremely secure, health risk communications, promotion of health practice, training, and you can see each one of these has different example systems that would be part of this.
Prevention, again public health prevention and can’t forget this one because it is the last word in the title for the CDC, and the functions with vaccination campaigns, wellness programs, smoking/drug cessation, violence prevention, and other types of different preventions that related to some of the intervention but different.
And again we have, when you look at the different information flows that might occur across the PHIN you can look at the different organizations and entities that might be involved which some of the traditional partners would be public health labs, some of the state and local health departments, law enforcement has become more of a player since 9/11 for a lot of what we do with different types of testing for things in criminal investigations. But again there’s a lot of the non-traditional sources but to public health may be traditional, looking at HIM(?) and RAD(?), if you look at vector control for something like West Nile Virus, the stockpile for pharmaceuticals, there’s a lot of information that can be overlaid with clinical information from the NHIN to provide a good picture of situational awareness as well as surveillance during routine times.
So the PHIN systems and standards, this is where we get to the connection to the NHIN and certainly at the top of this listing is the functional requirements, again we do have functional requirements related to preparedness with the PHIN now, there’s work going on to broaden those to some broader categories as we discussed before. Again the guidelines for workforce competencies, we need staff in the field that are educated in informatics and information technology so that we can build these systems to interoperate. Guidelines on policy and operations for information systems, and again PHIN is a set of applications delivered from CDC but also those partner systems or companion systems that are in the state and local health departments and in other agencies.
And the next few items, looking at vocabulary standards, technical specifications for message exchange and data transport, specifications for directory exchange, not one that’s listed in some of the core components for the NHIN but it would be an important one to look at routing for messages and other types of things. Technical specifications for alerting, again I’ll talk in a bit about what the PHIN or public health can give back to the clinical sector through notifications, alerts, and there are standards related to those areas that CDC and the PHIN have been working with for some time.
Security services, this is certainly covered in the core components for the NHIN. This is not uniform across the country, certainly at the federal level we have certain guidelines that we must abide by by federal law, if you look at PKI is it implemented consistently, the same certificate authorities and other things, authorization is different, so this is a tough one but it’s certainly something that needs to be done, is it federated and how do we implement that, it’s going to be an interesting one to look at but certainly a component of this.
So again PHIN and NHIN, what can be shared, I think this is the edge of the many PHIN systems to the NHIN so again around the standards and specifications that have been specified for the NHIN, and there is a lot of really good correlation between those standards that have been selected for NHIN and what PHIN has selected as well but there will be some synchronization need there as we move forward.
This relates to the NCVHS template, the diagram that we were sent, this is just a different representation of it where you see the two bubbles with PHIN and NHIN represented and the key is in the center are those core components for connection where data and information are exchanged. And then you see the edge systems for each around the outside, there is some overlap here, certainly there are hospitals and clinics and laboratories that are public health that do clinical care but this is just to demonstrate some of the different organizations and systems that might exist.
A key component of this I think is delivery of both clinical information and possibly combined with public health information, delivery to consumers --
MR. BLAIR: As you’re describing this, since I can’t see I’m just going to ask a little bit, could you describe to me exactly where, it may be visible on the picture, exactly where PHIN network and NHIN network, where they interface, at what point? Is that shown on your diagram?
MR. MORRIS: It’s shown in two bubbles that have overlap and I think what is in the overlap area is the common, is the core components --
MR. BLAIR: Could you tell me what those are?
MR. MORRIS: The standards, when you look at the NHIN components from the NCVHS template, if you look at terminology standards, if you look at messaging standards, transport standards and the semantics around those types of things, that’s where the overlap and connectivity will be. And I think it’s, again the edge systems that would be on the PHIN again are operating with a similar set of standards that are being recommended for NHIN so I think there’s a good correlation there.
I can come back to it in questions if we want to cover that some more. I apologize for not describing the diagram better.
And related to this I wanted to cover some different types of interaction scenarios between PHIN and NHIN or some traditional means as well as some that are pretty unique to public health but we do need information combined from many sources. West Nile Virus is a good example of this where you have information sources, could be from animal disease data, vector control data, and case reports possibly, source from the PHIN and their partners, and then human clinical data from the NHIN. Certainly this has been done in the past, many of these things are done but it’s difficult and expensive to do these interfaces now and there’s a lot of things on paper. So the better data we can get from all of these sources the better we’re going to be at prevention, guidelines, and hopefully reducing the amount of disease. So if you look at this scenario with West Nile the dissemination of information could be prevention guidelines, alerts and notifications to both PHIN and NHIN and many other things.
The second scenario would be of air quality and asthma, currently the Environmental Health Tracking Network at CDC is working with the EPA and the local EPDs to look at air quality data and doing a pilot to overlay that with asthma data to look at rates of asthma and clusters and different ways to do research on the data and provide guidelines. What would be the outputs of this? Certainly I think the EPA would be interested in evidence for regulatory control measure success, that if we can make these correlations that these regulations are helping to reduce, increase air quality and at the same time reduce related illness, community health research in general and air quality notifications to clinical care back to the NHIN.
So in closing I’d just like to make a few recommendations and talk a little bit to some more generalized pieces. Members of the clinical care and public health community have seen the benefit of a connection of information systems in the two sectors but I hope I’ve given you a picture of what this could become in the future as real integration is realized. While some of the interactions I’ve described occur today many are manual and those that are electronic require large investments of both time and money due to the lack of standards and interoperability specifications across both the clinical and public health sectors. In closing I would like to offer a few recommendations for consideration in the biosurveillance use case and NHIN functional categories.
First I think certainly for PHIN, and there are a lot of specification implementation guides and terminology together for the PHIN, that we need to synchronize those with those that are coming out as recommendations with the NHIN and the functional categories.
Number two, I think we need to extend biosurveillance use case to include data flows from PHIN to NHIN. It may not be specifically in what it was initially meant for but I think there are important flows for emergency response, for routine times just during different types of outbreaks, information that could be provided back for disease spread in a pandemic, for targeting counter measures or interventions to specifics areas based on disease spread, and certainly many other guidelines. So I think those need to be explored and built out.
As well we need to extend the biosurveillance use case to include requirements for routine surveillance needs and if not in the use case itself certainly in the data elements that we are going to collect as part of biosurveillance, I think you need to think about what you need to do with the data, if you’re going to look at environmental conditions, if you want to look at overlaying that with different things for animal health or zoonosis then I think we need to look at what those data elements are ahead of time, otherwise we’ll be catching up afterwards.
And again work with some additional partners, some of those that we don’t consider possibly in public health that could get us some of those other elements in how they might be used and include those in this conversation as well, either through the partners that we have on the committees and workgroups or directly, but I’d like to make that recommendation as well.
Thank you for your time and attention and I appreciate the opportunity to provide testimony today. Thank you.
DR. COHN: Thank you very much. Obviously we’ll take questions and conversation after we’ve had a chance for three presentations. Our final presenter is Floyd Eisenberg, obviously thank you very much for joining us today.
DR. EISENBERG: Thank you very much and on behalf of the HITSP Biosurveillance Technical Committee I thank you for the opportunity to present. It’s nice we have an interoperable machine --
What I will be doing is starting on the presentation in your handout on slide 28, as requested this morning I will not be repeating the prior HITSP slides that you’ve seen, in your testimony it starts on page 11 for biosurveillance. I won’t be reading directly from the testimony, they’ll be a lot of comments that sound like I’m reading directly but I’m not.
The first thing I think is important to state and I actually appreciate very much being at this point in the schedule coming after ASTHO and CDC because as our technical committee began its discussions and deliberations there was a lot of discussion about this is the beginning of a journey, we’re looking at a infrastructure to help to start to set down some infrastructure to be able to for now meet this biosurveillance use case as defined but an infrastructure that perhaps or hopefully will lead us toward population health. Which we’ve had feedback from some of the HITSP panel members, why don’t we call it population health, and the reason is because it is limited to start with but we’re being very careful to try to make sure the standards we choose, and I won’t be telling you which standards today because we’re in the process of finishing up what will be in the specifications as I think you heard yesterday, but I will be talking about some of the significant issues.
And the issues here are just a brief overview of our use case was moving from clinical care in multiple settings through the patient encounter, lab, now additional to lab results we have orders, we have radiology lab and orders to deal with, as well as resources, the utilization of hospital beds mainly, and getting that information to the BIS, or Biosurveillance Information System. The challenge there is there’s another, there are different levels of interoperability in that if we’re talking about an EHR or a hospital we’re still, ambulatory or hospital, we’re still dealing with do I send something to local in one format, regional public health in another format and federal in another, so hopefully this will help to inform how the responses in our interoperability specification that it doesn’t any one or how many send to it can transmit the data in the same format and be reused.
So that’s our intent and how we’re looking at this, the issue of anonymization or pseudonymization so that information can be re-identified as necessary and what we’re really looking at this is in two formats, we actually have these listed as functional scenarios which is the message based data submission which is more likely to be used in an ambulatory setting with, I’m sorry, I’m backwards, message based from the hospital in which data will be coming at different times, utilization is not necessarily going to be in a document based data submission but would be message based, but from an ambulatory setting may well aligning best with the work in EHR be in a document, perhaps a document share and queries from there. So we were looking at two different scenarios of sending information as well as resource utilization as another scenario.
In keeping with the biosurveillance which is a secondary use system different from the other technical committees we wanted to keep in context the clinical exemplars, the clinical scenarios, of pandemic influenza, bioterrorism, I’m using anthrax as an example, and through our committee it was agreed to look at a sexually transmitted disease as routine surveillance to show through our specification how it can be used for these purposes with the primary reason here for identification of situational awareness.
I do not intend to go through all the details on this slide of the message based data submission but just to explain that as we went through the use case we looked at all steps along the way into what we at that time called building blocks, as did the other technical committees, and based on what required new work, what was existing, what was a current effort, but also then took those down to the next level, just a reminder of process which I believe you heard yesterday, to our constructs which are transaction packages, transactions and components. In addition in working with the other technical committees we have, and this is one example of the slide, which shows the constructs specific to biosurveillance, there are constructs that are common to biosurveillance EHR, and constructs common to all three.
So we are working with the other technical committees to provide that, the reason I say this is a draft is its already changed since yesterday so one of these boxes, managing consistent time across enterprises, is now a common one rather then a unique one. But the point is that they are now developed into constructs for which specifications will be written and documents will be available on September 29.
Basically as far as requirements for the core system there are specific requirements, again we are as a technical committee in agreement with a thin core system, basically providing methodology for secure communication channels and note identification for managing machine credentials understanding that biosurveillance is not looking at a human sending data from an organization to an organization but machines sending information or devices sending information perhaps, or computer systems sending, but not necessarily a request to an individual. So in this case not necessarily the individual who was responsible for the information but where it came from as far as the system, that’s what is meant by machine, so to have a requirement for the edge system to have policies on issuing those credentials.
Also the ability for the edge systems to request filtering, not for the NHIN to do any filtering but in cases of a large scale event where public health needs to request additional data or a modification on how data is sent to the public health there needs to be a method to request that and that method needs to be a standard method. The filtering itself is an edge system that I’ll get to on the next slide but the ability to ask for changes is what we’re looking for here.
The challenge at this point in that the data that is being considered, because of the issues of data transformation from each edge system, and you heard that in the morning discussion on the EHR, we’re dealing with a minimal dataset to be able to manage in the near term public health surveillance, not what’s necessary for the long term what we all would like but for the near term. There will be some challenges if the filtering, if there’s a request to increase the filtering and there’s no standardization on the new elements, so we understand that’s going to be a challenge but we’re dealing with the minimal dataset to begin with.
The other area here we’re requesting for the NHIN is to manage related networks, for example there are networks today for emergency responders to understand hospital utilization emergency department availability. We’re being asked through our use case to provide similar but not as complete information to public health and if there are multiple methods and we’re creating new groups for which information needs to be sent what NHIN could help with is how to coordinate multiple networks, rather then having multiple but have them coordinate.
Another that was presented in the slide by CDC this morning of course was law enforcement in addition to emergency responders.
The other area for NHIN here is to support communication environment for secondary views of data, whether it’s public health, whether it’s researchers, we clearly see this as a biosurveillance use case, in the long term we see this also as the potential for sending information from the EHR for pay for performance, CMS, other measures and so there needs to be consideration for how other secondary users of data will manage.
As far as requirements for edge systems on interoperability to basically to support the three functional scenarios, to manage the message, document and resource, a methodology for data communication for secure point to point communication and shared document resource, high level crude filtering so that each edge could filter and in this case on the terminology side we would leave it to the local implementation to decide whether the sending edge or the receiving edge does the data mapping. There are benefits and challenges to each solution but rather then specify the architecture it was agreed among the committees that we may be better off allowing the local implementation decide which edge does that to see which works best for that organization, but the filtering occurs at the edge.
Associated services would include terminology services, security, and again pseudonymization services. Some of these services are still to be developed, we will define standards for them but some services such as pseudonymization may or may not exist in certain locations --
MR. BLAIR: What is that word?
DR. EISENBERG: I’m sorry? Pseudonymization which through the work with the committee, an ISO standard I understand is called pseudonymization --
MR. BLAIR: What does it mean?
DR. EISENBERG: It means basically providing an alternate ID so that the service could correlate data on the same patient, the issue provided by, I forget whether it was CDC or ASTHO that the same patient seen in one ambulatory setting and another and the hospital were all rolled up into the same patient but the receiving end in public health would only know it as an unknown patient but would be able to know that all that data relates to the one patient.
Another issue is timely data flow management which in our use case was an issue and we’ve heard anywhere from every 15 minute transmission to the most, or the least frequent, daily, so management of the data flow in that near real time as required would be an edge system.
And management of large volumes of data, one of the concerns that came up in a number of our discussions was an excess of data at either end, and especially at the public health end, could be overwhelming considering resources. And I think there could be excess at the other end as well and there are legal and policy implications that do need to be addressed as far as having information but not being able to respond to it, that needs to be carefully evaluated from a legal and policy standpoint, as well as workflow at the edge. Those are not IT specific issues but they need to be addressed to make it work.
In general the other comments the technical committee wanted to make was for syndromic surveillance and situational awareness, aggregate monitoring does happen today, it happens successfully in isolated sites, in groups and in regional areas, and successfully monitoring bed utilization and types of conditions for which patients are seen in emergency departments today. So rather then looking at it as a green field we can learn from this experience, HITSP can certainly enhance the process through standardization and we hope to do that.
The other significant issue in public health is probably more similar to clinical health care then it is different. In addition to the aggregate monitoring there is the need to give back to the individual level for either case identification and contact management and further epidemiology information collection, and that’s where the anonymization and pseudonymization, or whatever word you put to that, comes in.
Requirements for edge and core systems do inform and are informed by architecture and I think it needs to be a collaborative discussion over architecture, architecture cannot be ignored as we look at the methodology for biosurveillance, just as a comment.
The other comment here is many of the standard development organization efforts are working towards some harmonization and we have a number of SDO representatives on our team and they are also a moving target, there are some that are very close to approval but not approved, and it’s hard to say we can’t look at those when we’re trying to come up with those as solutions but our task is to be careful to take only those that are already approved. So we will be providing a roadmap as well as a list of what can be done exactly at the end of our deliverable.
So I want to thank the committee for allowing us and the technical committee to present, thank you very much.
DR. COHN: I want to thank the three of you for what I think has been a very interesting set of discussions. I know John Paul already indicated to me that he had wanted to have the first question, so please.
MR. HOUSTON: Thank you. I know Dr. Eisenberg spoke about it a little bit at the end, I didn’t really hear too much discussion about it in the other two presentations and so in the context of biosurveillance, I’ve heard a common concern from privacy advocates with regards to the release of identifiable information in the context of biosurveillance, especially without an authorization. Now I understand that clearly there are cases where there is mandatory government reporting, we know that exists and it’s necessary. But I get the sense that there’s also, I get the sense and I apologize if I’m going to say this the wrong way, that people see this as an opportunity almost as a land grab to get additional information and again I think in the context of people’s concerns over, individual accessing public health, individuals accessing identifiable information without authorization, it’s a concern that I’ve heard put in that context.
So I guess my question sort of is I’d like to hear from you generally about what your thoughts are on this and as well the rule of some type of an authorization scheme to release identifiable information for biosurveillance purposes.
DR. EISENBERG: Let me respond from the perspective of the HITSP Technical Committee. Given the timeframe that we’re working with we are addressing some of the security issues but some of them are being handled separately from our own technical committee. What I can say as far, and the committee has been very concerned about the issue of privacy and reuse of data with or without permission. We in our constructs have been very careful to say release, and I’m trying to remember exactly how we worded one of these, it’s not on the slide that I have here, but it’s release of information to authorized public health officials with the definition of authorized as based on policy allowed to get that information at that time. But that implies that there’s a policy that indicates when that can occur because in an aggregate situation we did not feel that this was an individual patient consent possibility because you can’t consent, unless you’re asking for consent every time you come in to a health care setting that your data may be used by public health and they may call you, anything else we felt was more of a policy issue.
MR. HOUSTON: But I think it is a concern though that individuals want to say yes, I allow my data to be used for biosurveillance purposes and that they would authorize that, that’s at least one very clear message that I’m hearing from a group of individuals.
DR. COHN: Well, John Paul, I guess the good news, on the one hand there are policy issues there which I mean I think are legitimate policy issues, I’m actually reminded that I think Dr. Loonsk yesterday reminded us that there’s actually a whole group that’s set up to try and resolve that.
MR. HOUSTON: I understand that but I didn’t hear any discussion from a technical perspective from, I think to the presenters really about that, the importance of it, relative importance of it as well as how it fits into all of this maybe.
DR. EISENBERG: Well what I can say is in, as future use cases are evaluated for issues such as research, which would not be public health, then consent does come back into the picture. We were limited to only public health or situational awareness and that was, and reporting is actually not in our use case so we were being very specific to for these purposes it’s not necessary. But once you get back to research and something beyond the routine surveillance and situational awareness the committee did agree it was a matter of more scoping for the time being but not to say that it’s not significant.
MR. MORRIS: I think that certainly in CDC we get a lot of anonymized data through case reporting and other means and what the biosurveillance work that’s going on currently with BioSense(?), the pseudonymization or pseudo anonymization is in place where it can be linked, again back to policy, should all those patients sign something to say that it’s okay for that data to flow to that type of system, I don’t know how doable that would be but certainly the protections are there and the only keys to that shop are on the side of the data source, so certainly we can use that as it was explained for aggregation of records for an entire encounter but it’s only linkable back and generally at the CDC level, at the national level, that linking back or any reach back to identified information would generally be at the local level. Now where do you get into authentication policy and how you distribute out those types of rights or policies to that, I think that’s something that needs to be looked at in how you step that in the hierarchy because there’s different levels of use and different needs to see more identified data at different levels.
DR. COHN: John, did you have a comment?
MR. LOONSK: Yeah, I just wanted to comment that clearly some of the areas of discussion here are very policy oriented, are highly technical, relate to existing laws and regulations in the circumstance of both state and local and HIPAA, and that it may not be fair to ask these testifiers to comment on those issues fully in that context. We have every reason to believe that, and are confident that the biosurveillance use case was compliant with federal regulations in regard to what it suggested needed to be done, that was in general nature and architecturally indeterminate in many respects. The areas of system services for filtering and for the linking seemed to be very much in the scope of discussion here in that context and so perhaps the sweet spot here relative to functional requirements is to make sure that the functional services and capabilities are considered in the context of supporting those activities.
MR. BLAIR: I have a little anxiety asking this question because I’m just not sure how much of this might have been displayed on the graphs, I’m really actually very, very supportive of trying to use a health information network capability for clinical research, public health, biosurveillance. And I’m saying that first because I’m struggling trying to sort out, our mission is to identify the minimum core set in the NHIN, so maybe you can help me. When I listened to the testimony on this panel it appears to me that there’s aggregation of information, widespread collection of information or monitoring of information, and I’m an old guy and I remember when we were looking at electronic health records at one point and we were looking at them for patient care and response time was important and performance was important and we had a whole different set of users and we started to separate out usage across patients into data warehouses separately so it wouldn’t impact performance. And I know things have improved so I’m, as I’m hearing these things I’m almost wondering whether since there’s a PHIN, Public Health Information Network, in addition to the NHIN, can a lot of this cross population aggregation of information be done on the PHIN? Because that means that we could keep the NHIN thin in terms of functionality so we don’t have to deal with data aggregation on a widespread basis for the NHIN and maybe there’s an obvious answer and it was already there, maybe you could help me with those thoughts.
DR. EISENBERG: Well let me state from the technical committee side and with somewhat of a health care vendor hat as well. It is potentially problematic to expect a consistent stream of data going across the NHIN as the operational system functions and as clinical users use it. The consideration was thinking, our committee was really thinking more of packets of information being sent at specific time intervals, what NHIN can potentially help with is what is the acceptable timeframe that we have some wanting it sooner, more frequently, and some wanting real time and some wanting every day but if we could help standardize what frequency is really necessary so that the edge sending systems could appropriately manage that through some type of data warehousing or whatever method they feel best, if they feel they can do it out of the operational system so be it but that would be the edge system requirement. I know that --
MR. BLAIR: So you’re not looking at the NHIN to have in its core minimal thin set of functionalities capability for data aggregation?
DR. EISENBERG: No, we were not.
MR. BLAIR: Thank you. And please continue to elaborate but that was one aspect of what I was trying to understand.
DR. EISENBERG: Well that would actually be the subject of about an hour long presentation I’ve given but I don’t know that I want to try to summarize all of that here, I’m representing the technical committee and we haven’t really fleshed out that whole issue of how will the edge system do it but just that it will do it.
MR. BLAIR: Okay, thank you.
DR. COHN: Kevin.
DR. VIGILANTE: Thank you. I’m not sure who would be the best to respond to this, maybe none of the folks here, but how does the PHIN and the NHIN, how do they relate to the NBIS, the National Biosurveillance Integration System? And what implications does the NBIS have as we think about the NHIN?
MR. MORRIS: There’s probably others that could answer this better then I but I think NBIS seeks to look across different sources, much like we talked about in a West Nile scenario but something more in a bioterrorism or other situation to look at these different sectors, be it veterinary, plants or clinical human health and other things and do some bit of early earning itself, at a next layer up I think some of the things that they are struggling with is the subject matter expertise to do the algorithms at these edge system that aggregate at the lower level, that’s where that subject matter expertise exists. So I think it is another layer of that because some of those feed some rolled up information to that or the early detection, I don’t know.
DR. VIGILANTE: So is there significant collaboration between, when we think about standards development and the like is there significant overlap and collaboration with the NBIS enterprise?
MR. LOONSK: This is John Loonsk and I’m taking off my ONC hat for a moment because I did have something to do with PHIN in the past and wanted to make a clarification because I think it’s an important one. As the testifiers suggested they are not suggesting that the NHIN accumulate data nor does PHIN accumulate data, PHIN has been a framework much like is being discussed with the NHIN, a framework of standards and communications, it is not a data aggregation system per se. There are edge PHIN systems that do as in accordance with state, local and federal law accumulate data as public health is enabled under HIPAA and in other contexts. And this is a proposed data aggregation system, it could be considered an edge system on the public health network, it does have interactions with other sectors as Tim Morris has suggested as well, and that’s sectors such as agriculture and other domains. So hopefully that clarifies a little bit.
DR. COHN: Floyd, I actually had a question here and I just wanted to maybe delve into it for just a minute. I think we’ve seen data filtering as a term that has floated around between edge and core and all of this stuff. Obviously you’re using a term of art described as high level crude filtering and I guess I’m trying to figure out what exactly, I mean why are you making comments like that and what is it that you mean by that, is that something that we should be aware of when we think about functional requirements?
DR. EISENBERG: The reason for the term high level crude filtering was specific to the fact that we’re dealing with a minimal dataset and we weren’t looking to participate for biosurveillance in the near term, that all information at the edge had to be fully mapped to some standard terminology to be able to be filtered. That was the reason for the I guess less then specific filtering comment because it is dealing with a minimal dataset. There are challenges with that in that as soon as something more is needed it’s not defined yet so that dataset would be expected to grow and over time it wouldn’t just be high level and crude.
DR. COHN: Thanks for the clarification on that. Other questions or comments from the workgroup? Okay, well I really want to thank our presenters, I think this has been a very useful additional dimension to our conversation around functional requirements and certainly an area that we need to keep in mind as we look at core and edge and trying to sort of identify a set of functional requirements to obviously meet multiple needs.
Now we are at 12:07 I believe, what we will do is to take a lunch break and reconvene at 1:00.
[Whereupon at 12:10 p.m. the meeting was recessed, to reconvene at 12:10 p.m., the same afternoon, July 27, 2006.]
Agenda Item: Panel VII: Other Health Information Stakeholders
DR. COHN: We are going to get started with the afternoon session. Before we move into our speakers, I actually wanted to give a member a chance to introduce himself, as well as identify any conflicts of interest.
Kevin.
DR. VIGILANTE: In the next panel, Mark Adams from Booz Allen Hamilton will be speaking, although he will be speaking as a caBIG employee, contractor/employee. I would also like to note that I am employed by Booz Allen Hamilton as well. If any conflicts arise, I will note them and recuse myself accordingly.
DR. COHN: Okay. That is Kevin Vigilante --
DR. VIGILANTE: My name is Kevin Vigilante, member of the committee.
DR. COHN: Okay. Thank you.
DR. COHN: This panel is really a variety of I think what should be very interesting testimony from a number of different perspectives. We are going to start out with Didi Davis and, Didi, as I understand, you are the director of Integrating the Healthcare Enterprise. So, we are obviously pleased to have you here for testimony.
Following, you know your agenda, it says that Kevin Hutchinson will go next. Kevin is, I believe, is going to be calling in by phone and we are going to put him at the end just because I think that will work better in terms of the conversation.
So, following Didi will be John Apathy and then Vish Sankaran from the Federal Health Architecture. Obviously, we are pleased to have you all joining us for the conversation.
Now, what I told other panels is is that we are trying to hold the actual testimony to about 15 minutes a person, with the issue being that, obviously, we have lots of written information from you and we really want to make sure there is enough time for questions and discussions about the information. So, your help on that would be appreciated.
So, with that, Didi, why don't we let you start and thank you for coming.
MS. DAVIS: Thank you for welcoming me and allowing me to have time to talk.
For anybody who doesn't have it, all of what I am going to talk about -- we have a power point presentation that this is presented by. It is in a packet that inside of here and I think there are extra copies in the back as well. There is also written testimony that I will be referring to a few pages so that you can have the highlighted notes, so you won't have to do a lot of note taking.
I apologize for not making them available ahead of time.
I am as was introduced director of Integrating the Healthcare Enterprise. It is an initiative that actually has been around since 1998. So, what I am going to do is to fill in a few gaps. I understand there is a lot to be covered, but I will answer your questions that were proposed, but I wanted to also set the tone a little bit about what IHE was real quickly.
One of the most important things I think that IHE brings to the table is that care providers and vendors working together to actually create implementation guides of standards. So, what Integrating the Healthcare Enterprise really does and some of the things I will be covering is it plays a really important role in my mind and in IHE's with the foundation, what we have put together, for really creating a truly interoperable world at some point in time.
It is an incremental step approach. IHE does not have everything that you need to build an entirely interoperable world today, but it does have building blocks and I am going to try to weave that story and show you some of the connectivity for that. But it is not -- one of the things I want to clarify -- a lot of people think it is a standard development organization. It is not. We leverage standards that exist. They are balloted and approved standards from every place from ASTM, you know, the HL7 standards, the DICOM imaging standards and so forth.
It takes about 16 standards to implement a truly interoperable end-to-end solution if you consider security auditing type of standards and so forth. IHE does provide a common framework for passing that type of information across enterprises, but also within the enterprise because there is interoperability problems between the departments within the institutions themselves as well.
So, what IHE does is it creates what we call integration profiles that actually pull those things together and those same integration profiles can be used not only inside the Enterprise but across Enterprises across state regions as well.
IHE here in North America is sponsored by three primary sponsors, HIMSS, which is the organization I work for; also, the American College of Cardiology and the Radiological Society of North America. Like I said before, IHE has been in existence since 1998 and it is an international organization as well.
So, building upon that, we do have chapters of IHE within Europe, Asia, North America, which also does include Canada. There is IHE Canada as well. There is a Strategic Development Committee that oversees the full strategic development go forward plan and road maps are put together as strategic road maps that can be used over a course of three to five years out at a time.
It is a proven adoption process, as well. So, IHE is not only an initiative, but it is also a proven process. It starts with identification of a problem or a use case, similar to what HITSP is doing within their various departments, identifying standards that may be used to help implement profiles that would help with that interoperability problem. Those profiles become what are called the technical framework. They are folded into the specifications. Nothing but documents.
It does go a step further not only creating the implementation guides, but also being tested at what we call a Connectathon. Here in North America there is a Connectathon that happens every January. The last Connectathon happened earlier this year. We had over 350 engineers from over a hundred different companies represented there, everything from cardiology systems to radiology systems to the normal electronic health record systems.
That leads to demonstrations at the various annual conferences that the sponsors hold every -- American College of Cardiology has one in March. HIMSS has theirs in February. RSNA has theirs in November. All this detail is again in your written documentation.
Hopefully, that leads to products with IHE baked into the product. So, vendors have adopted this as a way to go forward with interoperability and they create what are called integration statements saying that they do have this version of software that can do this. They can act as a patient identifier, cross referencing manager to create -- figure out how to link all the different identifiers for a patient. Hopefully, that allows you to have more of a plug-and-play type of product, rather than having a lot of point-to-point interfaces that is required today.
There are nine domains within IHE. So, it is not just radiology, although that was where it was born from. If you think about the background for it, a bunch of radiologists got together and said, look, I am tired of putting in the patient name in my order entry system and then again in my RIS system, the Radiology Information System and then in a PAC(?) system. They were having to put it in three different places.
IHE was formed on that basis of saying let's make this electronic and seamless. Now it has grown. This is 2006. We have nine domains. You will notice on the slide that underneath each of the bubbles, such as radiology and laboratory, it has the number of profiles listed underneath it that are in existence today.
For instance, radiology has 17 profiles, being the oldest. Now I go on to kind of answer a little bit more about your questions that you had proposed and if you want to actually turn to page 14 of the written document, it is the written testimony, that is where I am going to list a lot of what I am talking about. So, if you want to follow and use that to make notes, I wanted to put that to your attention.
My document, "Sharing of Data," IHE feels that we are building upon an infrastructure that can be flexible and that can be extended for an interoperable architecture. Now, what I am going to do is address this, saying that IHE has pieces. I am not going to say they have the end-to-end components. They have pieces that could be considered building blocks to do things like patient data record locations, can do the transport, the security, the audit trails and authentication that you have in the middle box. Now, in your document on that page 14 is this same blue box that you have here. The integration profiles are listed on a web site called WWW.IHE.NET. All of the actual documents that I reference in this slide are all out there and you can bring them up, look -- some of them are 20 pages and some of them 300 pages. So, I will warn you there is a lot of reading out there. But by piecing these together -- and I truly really reemphasize what we have done with IHE is we have put together building blocks that depending upon the work flow that is required within that physician or clinician's work space, the radiologist, the pharmacist, whoever it is that is working with the patient to help with the patient care, with the delivery process, there are the building blocks.
What we have done is we have structured it on what we call a Document Sharing type of framework and we call this profile in IHE, XDS, Cross-Enterprise Document Sharing. I am not going to get technical with that, but just trying to get to the point where in addition to that profile, there is a profile called Audit Trail & Node Authentication. So, somebody alluded to earlier the machine-to-machine communication that is necessary for biosurveillance and so forth. That node-to-node authentication thing, yes, I trust you with the computer. I will send you this data and so forth. That has to happen.
There has to be a consistent time when you are looking at documents and you are looking at lab results that are three hours old. You need to know if it is three hours old your time or is it three hours old Pacific Coast time.
So, you have got to think about certain things like that as well. These things are grouped together to create that interoperable infrastructure. This has actually been demonstrated at these annual conferences that I mentioned about the sponsors. So, these are pieced together to create the interoperable world that you have seen maybe in some of the actual annual conference presentations and demonstrations that occur from the process.
But because the component literally that is alluded to here in the -- you will see starting on page 14, it goes into in depth, we even profiles that allow you to do the point-to-point sharing. We have an infrastructure that has registries so that people could go and query, not knowing anything more than a patient identifier if there is anything that exists or they can go query directly to one institution. So, if we did have a public health information network and it had its piece together, it could actually pull data from some of these registries or repositories, as well.
Now, these documents that are created within the IHE framework are true documents. They are based on the CDA standard within HL7. There is discrete data, XML-based, within that document. So, at this first step we are trying to make something that any EHR, whether it is a smart EHR or not a smart -- a smaller, you know, maybe a smaller physician practice EHR that doesn't have all the bells and whistles that an acute care setting might have.
Trying to pull all that together, not to say every vendor can digest that information yet, but the information is there so that one day when that semantic interoperability is achievable, the data is available and you can pull that.
So, all of these things are grouped together. There is a profile you will notice listed at the bottom right hand corner under "Other." There are two there. I will mention because I happen to know this number. Somebody gave this to me. The request form for data capture is actually building block No. 39 in the HITSP work. HITSP is also leveraging a lot of this work, which leads me into how they are looking at kind of bringing this together.
I am not going to spend a lot of time on this next slide, allowing the edge systems to speak to one another because the EHR Vendors Association and Charlene Underwood did a very good job of presenting it. But the IHE profile we see as truly the building blocks that will the edge systems to connect. They are, hopefully, the standard ways of sending that data between the edge system, electronic health records, pharmacy, you know, benefit systems, wherever the payers, wherever this data exists, sharing that data from the edge into the network so that it is discoverable at that point.
The requirement, too, that they talked about was flexibility. I would like to point out there is a profile within the IHE process that I alluded to earlier for the patient identification, cross referencing of information. It is called PIX, patient identifier cross-referencing. That profile has been looked upon and investigated to not only within like the CSC NHIN contracts for being able to talk between record locater services, but also being leveraged from the edge systems to talk up to the record locater services.
So, that is an example of a profile that IHE has that is flexible, that can be used within a RHIO, Regional Health Information Organization, or it can be used across RHIOs, across an NHIN type of implementation. So, we feel that that is a flexible type -- that gives you an example of how the flexibility is built into these profiles.
Again, this needs to incrementally happen. So, what Charlene had pointed out earlier in her testimony that this has to be across phases, there is an interoperability road map, that the EHR Vendors Association has put together that has built this out, again, using the IHE profiles.
I mentioned earlier the Cross-Enterprise Document Sharing that was shown. This is a very good picture, depiction of how that is done. The scenarios that we actually showed, we had 16 scenarios in the Interoperability Showcase at HIMSS. That is the one I am the most familiar with because I helped put that one together for the last two years. We had everybody from VA and the DOD sharing documents and showing how this scenario could bring in everyone from a soldier down to a cardiologist doing referral back to the primary care provider after they had finished with the visit and the cardiac type of care.
So, this is discharge summaries, medical summaries. There are emergency referrals. There are content profiles within IHE for eight different types of documents and those are everything from personal health record document content down to the normal discharge summary type of information that you need to share.
MR. BLAIR: Would you mind reading off those eight documents, please?
MS. DAVIS: The eight types of documents: medical summary. There is a discharge summary. There is a personal health record summary. There is a referring to an acute care setting and a referral document to an ambulatory care setting. I think I mentioned the emergency department one already. You put me on the spot. So, I am trying to remember the last three.
There is a consents document. That was the new document created this year, basic privacy and consent document. And I cannot remember the last one. I will have to look it up and let you know, but I will definitely make sure to get you that information. I just can't think of it right now. It is in this testimony as well. So, you can find it there.
So, again, that gives you an idea of what we mean by these document sharing type of processes, not to say that that will change the world immediately, but that will give more information at the right time, on the right device for that clinician to provide hopefully better care. Now, these data elements within the documents started off, for instance, the medical summary document last year was very small amounts of data; allergies, medications, problems list. That was it. It is starting to grow, for instance, the emergency department referral has a lot more information now.
To showcase this last year at HIMSS, I put one information in here because I had all of this information on a slide, but in the written documentation, it gives you statistics on all the annual conferences that the other sponsors have had. The Interoperability Showcase had over 3,000 attendees go through the showcase and there were 26,000 people at HIMSS total. That was better than 10 percent.
Thirty-seven vendors all showed product with this. So, with that, we are also leveraging the integration profiles are being used by HITSP. CCHIT in turn, hopefully, will at some point in time in years 2 and 3, leverage those as well.
So, in summary, really the role of IHE is, hopefully, the IHE integration profiles can provide models for harmonization because it does -- for instance, the XDS profile uses about six different standards between the security and so forth.
These building blocks can be put together to create this infrastructure that will allow you to not only connect to the NHIN, but also hopefully may be become pieces and parts of that. The implementation guides for interoperability specifications are freely available. They are domain free of charge. There is no charge for leveraging of those and we encourage many of the NHIN contractors to come to the table.
With that, I am finished.
DR. COHN: Didi, can I just ask you -- you went through slide 15 without comment. Is there anything there that we should --
MS. DAVIS: No, these were -- basically, what we did, what is missing in these, clarity. What we did was we took some of what you have listed as the functional requirements and we listed out what we have considered up to this point and the timing of what we have already put them together as. So, if you remember the EHR Vendor Association Road Map, Phase 1, Phase 2, that is what this is referring to. So, we tried to tie this together for you so you will see what is available.
One other thing that I might want to point out real quickly, because it is color coded and it wasn't very clear for you to maybe see and I am sorry I am having to go backwards there. These are color coded as well. You will notice the blocks in green are all fully available. They have not only been tested in a trial implementation. They have been tested as a Connectathon against at least three or four other vendors by every other vendor.
The ones that were added in 2005 are in orange and the ones that were added in 2006 are in the light blue. So, that gives you an idea where we are.
DR. COHN: Okay, Didi. Thank you very much.
The next presenter is John Apathy.
MR. APATHY: Dr. Cohn, thank you. I am John Apathy. I am a senior executive within Accenture's Health & Life Sciences practice. I want to first thank you for allowing me the opportunity to speak on behalf of a wide array of stakeholders from the Clinical Research Community. Just a few of the members of this community are here with me today and I wanted to just real quick acknowledge them.
Dr. Peter Highnam, special assistant to the director at the National Center for Research Resources at NIH.
Maggie O'Connor, she is with the Global Drug Development Information Systems Group at AstraZeneca.
David Isom and Dr. Ross Martin, both within the Regulatory and Healthcare Informatics Group at Pfizer.
Although our broad group has not had sufficient time to fully discuss and come to complete consensus on all the detailed plans and recommendations that I will be describing, we nevertheless welcome the opportunity to present a high level perspective to NCVHS at this time.
Collectively, this broad stakeholder group is aligned on the promise that the Nationwide Health Information Network can and will be a key enabler to improving public health by transforming Clinical Research, expediting the development of new ways to prevent and treat diseases and improving the lives of Americans through better, safer disease prevention and treatment options.
Since March 2006, Accenture has been working with a small group of pharmaceutical companies that has included AstraZeneca, Bristol-Myers Squibb, Pfizer and Wyeth, to evaluate and explore how Clinical Research could be improved by leveraging the NHIN and other Health Information Exchanges. This effort was named the NHIN Slipstream Project. This group explored many important ways that the exchange of health information could improve patient health through the research, development and commercialization of new therapies and determined that the three most important areas of initial focus in the ONC NHIN process are post-marketing drug safety surveillance, connecting patients to clinical trials and establishing appropriate care standards through outcomes, pharmacoeconomic and personalized medicine research. The group has spent the past few months developing documentation for these use cases and will continue by determining the data elements necessary to support them and the value propositions and business cases for each set of stakeholders.
Based on the work done through the NHIN Slipstream Project, our Accenture-led NHIN prototyping consortium included 11 requirements related to Clinical Research that is now among the 1,100 plus requirements submitted to the ONC in May. These 11 requirements as you see listed here all beginning with the ACN prefix are 01.10, 01.11, 01.12, 01.13 --
DR. COHN: You don't need to read them.
MR. APATHY: For those who might not be able to see the slide.
Very good. Sorry.
Additionally, as a final step in their development, we intend to make these use cases available to the NCVHS, the AHIC and other interested parties for further critical review, comment and use.
On May 9th, groups such as the group FasterCures, the National Institutes of Health's National Center for Research Resources and the Agency for Healthcare Research and Quality, AHRQ, sponsored a meeting of Clinical Research stakeholders to determine how to include clinical and translational research in the design of the NHIN and other HIEs.
The meeting broke into work groups to identify the highest priority Clinical Research use cases and there was agreement upon the same two use cases of connecting patients to trials and enhancing post-marketing surveillance.
After realizing the alignment between the research community and the group of pharmaceutical companies participating in the Slipstream Project, FasterCures and Accenture sponsored a meeting of the two groups on June 15th that was attended by representatives from NCRR, AHRQ, NCI, the Mayo Clinic, Fox Chase Cancer Center, Memorial Sloan-Kettering Cancer Center, Intel and the four pharmaceutical companies from the Slipstream Project.
This group met to explore the best way to work together to ensure that the priorities of the Clinical Research Community are included in the design and requirements for the NHIN and other HIEs. The group agreed that a key principle in all the efforts to develop use cases and the NHIN design should be to consider patient needs and patient care as the first priority. The group has remained grounded in keeping the patient's needs as a top priority while developing the connecting patients to trials, drug safety surveillance and appropriate care use cases.
We will continue with this patient focus going forward. Participants from this group of Clinical Research stakeholders attended the open forum on NHIN requirements held by ONC on June 28th and 29th in order to support the inclusion of Clinical Research requirements and to participate actively in discussions and breakouts. During this forum, it became clear to the Clinical Research group in attendance that the biosurveillance use case that has been developed as part of the NHIN prototype projects has many similarities to the drug safety surveillance use case being considered for Clinical Research.
The group believes that many of the architectural designs, policy issues and data requirements for biosurveillance also apply to drug safety surveillance, which is another form of public health. The group feels that this alignment between the two use cases may be a good starting point for Clinical Research organizations to contribute to the development of the NHIN infrastructure and to drive standards adoption efforts.
Immediately following the Open Forum, Dr. Brian Kelly from Accenture represented this group and presented testimony to a subgroup of the NCVHS asking that Clinical Research be considered in the requirements for and technical design of the NHIN. Several of you, as members of NCVHS, voiced support for the inclusion of Clinical Research in the NHIN and urged the Clinical Research Community to consider two important points. (1) How can Clinical Research contribute to the business model and funding necessary to build out the NHIN and drive the necessary adoption of standards and (2) how best to work with patient advocacy groups to build an understanding of the importance of health care information sharing for Clinical Research and public safety, which can use this shared information to delivery important new treatments to patients faster and better ensure the safety of approved medications.
DR. COHN: John, I don't mean to break in. I know you have a relatively long presentation and I am pretty convinced that you are going to far exceed your 15 minutes. We obviously were here and took that testimony. I am actually wondering -- and I apologize to sort of break in, but I am looking at your slide pages 6 and on as being particularly relevant to the testimony today. So, I guess I would hope that you would use the next couple of pages -- if there is something here critical, tell us about it, but let's move to the -- make sure we have time for the key issues.
MR. APATHY: I will do that.
I guess one of the key points that we would like to make are in the coming months the Clinical Research Community plans to share its work on these use cases and utilize all the documentation and the work done on the value proposition, the business model to both initiate proof of concept projects but also to -- in other words gain real life experience to prove out some of the use case utility.
I think that I would also make the point that a proposal that is being discussed and desired to have a private/public collaboration and the opportunity perhaps to have a working group underneath AHIC that would be specifically focused on the Clinical Research concerns.
So that was summarizing those points from the rest of that opening testimony.
So, in summary, we strongly believe that the NHIN could support Clinical Research activities and functions and the time is right to engage in the discussion about the next steps we need to make. It is in this context that I would provide the following responses to the questions posed by NCVHS.
Regarding what are the minimal but essential network functional requirements for the initial roll out of the NHIN, the functions for the nationwide network itself and not for specific edge systems, in order to best enable Clinical Research, including the matching of patients to trial, post-marketing surveillance and other population-based aspects of Clinical Research, the NHIN must support several key components of functionality.
First, the NHIN must allow all pieces of electronic information about the health of a patient to be designated as belonging to that unique patient. In order to do so, the NHIN and all systems that connect to the NHIN must be able to identify that a record or document is associated with that unique patient.
So, a lot of the systems request information about a patient from one another and ensure that all the systems are referring to the same individual. In order to conduct the population-based analysis required for several Clinical Research and drug safety use cases, it will be necessary to study complete longitudinal health information across a large sample size of patients.
For these aggregate data uses, it is not important to know who a patient is, but rather that all pieces of information have been identified as belonging to a unique patient to make up the complete health record for that patient. Therefore, robust enterprise master patient identification must be a key component of the NHIN.
Second, the NHIN must contain robust record locator service functionality that can locate all pieces of health information about a given patient from all data sources. Many types of data source systems will exist, containing a variety of data about each unique patient. Upon request, the NHIN must be able to pull all of these pieces of information together to make up the complete, longitudinal electronic health record for a given patient. This ability to view and query against all patient health information is necessary to support improved Clinical Research, drug and medical device development and safety monitoring.
Record locator services can be of varying degrees of sophistication. In a simple form, they can consist of essentially a directory, which catalogs the location, where patient data exists and more complex implementations contain the business logic for determining what data is returned with on query for information.
How much of the type of business logic that resides in the core as opposed to edge systems will need to be determined. Most likely, much of the business logic will reside in the edge.
Third, the NHIN must supply the infrastructure to support the exchange of all types of electronic health information between core and edge. This infrastructure includes the identification and implementation of messaging, document exchange and terminology standards to support health information exchange. These standards must initially support exchange of health documents between edge systems using standard header information.
I think the prior presentation addressed this in quite good detail. In order to realize the true benefit of health information exchange for Clinical Research, particularly drug safety surveillance and population-based analytics, may types of health data exchanged via the NHIN must be structured, standardized, normalized format that supports data analytics. The NHIN must define the message and terminology standards it will accept, which should then drive the adoption of standards by edge systems wishing to connect to the NHIN to exchange and receive information.
Finally, the NHIN must ensure data security, patient privacy by thoroughly controlling access to patient health information. In order for patients to support and consent to the use of their data for Clinical Research and drug safety surveillance, they must trust their data is secure when exchanged between edge systems will only be accessible to authorized individuals and will be used appropriately for the delivery of care and secondary uses that are in the interest of improved healthcare quality.
The NHIN design must accommodate where and how a patient's consent to share his/her data is acquired, recorded, managed and implemented. While often technical components for the management of a patient's consent may reside in edge systems, the overall NHIN architecture must provide guidelines for these functions and how the edge and core systems interact to handle the critical function.
Regarding specific edge systems or entities, what functions should be minimum but essential for linking to the network? In order to support the needs of Clinical Research, edge systems must be capable of several functions when connecting to the NHIN. First, edge systems must have well-defined processes, policies and enabling technology to capture, store and report clinical data in accordance with standards for Clinical Research, data capture and management.
Additionally, edge systems must also anonymize and re-identify patient health information for various audiences based on agreed security and access rights. Many aspects of Clinical Research are population-based analytics that do not require knowing who a patient is, but rather require visibility to the entire longitudinal health records. The technology and policies must be in place to support anonymization and aggregation of patient data and re-linking to identify patient information upon request by authorized entities.
Second, in order to fully support many Clinical Research uses of health information, edge systems must be able to semantically normalize health data to accepted messaging and terminology standards before transmitting messages or documents through the NHIN. Edge systems must be able to translate terms from local standards into format and technology accepted by the NHIN for information exchange. Health information that is standardized is critical to the ability to execute data analytics to derive research insights and detect patterns relevant to the safety of medications and medical devices.
Edge systems must also contain the necessary patient identification services necessary to link data to a unique patient and record locator services as described above, capable of handling requests for data from the NHIN. It is likely that much of the business logic that will control the data will reside in edge systems.
Finally, Question 3. The HITSP is identifying standards for the NHIN and for specific use cases. What additional HITSP considerations are there regarding Clinical Research?
The use of messaging and data standards is critical to the use of electronic patient health information for the purposes of Clinical Research. Many different categories of patient health information are required to fully enable the Clinical Research use cases, including patient demographics, allergies, family history, personal health history, clinical diagnoses, basic clinical observations, labs, procedures and pharmacy data. Additionally, standards for data exchange for genomic and proteomic data will be required. Each of these types of data must be standardized into accepted terminologies and formats to support the data analytics required for Clinical Research and public safety.
For example, standards such as SNOMED, MEDDRA and ICD-9 will be important for the analysis of medical diagnostics. The LOINC and ICD-9 standards will be important to analyze laboratory data and results. Procedure data should be captured in terminologies such as CPT-4 for analysis and pharmacy data should be captured using standardized terminologies like RXNORM. Theses types of terminology standards, as well as other types of terminology and messaging standards like HL7 and CDISC will all be critical to the data analytics that will be required to support Clinical Research.
So, in summary, our informal consortium and the represented parties of the broader U.S. based Clinical Research Community believe that the NHIN can be a transformational capability to improve public health and Clinical Research and expedite the development of new ways to prevent and treat disease.
In fact, we believe it is an essential next step for the U.S. to remain competitive in the world's global economy with respect to biomedical research and human health and relevant in discovering the next generation of medical breakthroughs for America's health. We strongly urge the National Committee for Vital and Health Statistics to work to ensure that the future NHIN supports Clinical Research. The patient is waiting.
I want to thank you for the opportunity to testify on this matter.
DR. COHN: John, thank you very much.
I also want to note that as an appendix, you actually have listed out the various functional requirements. So, thank you very much.
Our next presenter, Vish, and then we will have Kevin Hutchinson finish. Kevin, are you on the line?
MR. HUTCHINSON: Yes, I am.
DR. COHN: We have one more presentation and then we will ask you to testify.
MR. HUTCHINSON: All right. Thank you.
MR. SANKARAN: Members of the committee, thanks for the opportunity to speak today on behalf of the Federal Health Architecture Program. My name is Vish Sankaran and I am the acting program manager for the Federal Health Architecture Program within the Office of the National Coordinator.
As many of you know, FHA, through its Standards Work Group, Consolidated Health Informatics or we call as CHI, has worked with NCVHS for the past few years. We thank you for that support.
The Federal Health Architecture role is to help create a federal health and IT environment that is interoperable with the private sector and supports the President's health IT plan enabling better care, increased efficiency and improved population health.
FHA contributes to the President's health IT plan through three main goals, by providing, one, input through a coordinated federal voice and collaboration on national health IT solutions.
Two, implementation guidance to federal agencies through advanced interoperability.
No. 3, accountability and assistance in measuring the adoption of interoperability by federal agencies.
All federal agencies within health care activities participate in Federal Health Architecture. The FHA partners includes approximately 350 members from 20 federal agencies that cover five health domains that include access to care, population health and consumer safety, health care administration, health care delivery services and health care research and practitioner education.
In June 2006, FHA informed, involved and compiled input from over a hundred individual federal stakeholders from 20 agencies in the FHA NHIN functional review process. The review teams were aligned with the roles shown in the bottom half of this particular slide.
We are here today to provide an overview of FHA's contribution to the NHIN functional review process. FHA has conducted a gap analysis of the functional requirements and will be submitting three documents for the committee's consideration. A copy of our presentation, a summary report on FHA's review of the functional requirement and the third one, a spreadsheet with detailed comments.
At this point, I would like to turn the discussion over to Laura Tillery from the Department of Defense, who will provide further details on FHA review process.
MS. TILLERY: The process that we went through was quite laborious, I think, in some fashion. As mentioned, we had five review teams organized according to functional roles, such as provider, payer, researcher, surveyor. Those roles then were headed by different agencies and had also a co-chair, looking from both a functional and a technical aspect.
The kick-off meeting occurred on the 23rd of May. We had general collaborative sessions that occurred and then more breakout sessions that occurred, reviewing the 900 requirements or more. We met and consolidated all those requirements up to the 27th of June and from there the representatives from the federal agencies were able to take the consolidated spreadsheets to the NHIN Forum as consolidated of what the federal of these were in the different agencies.
Since then we have been able to further distill and collaborate and summarize many of the comments down into this summary sheet that you have in front of you, about 20 pages for your benefit.
Just some general observations from our review process. As noted, I think probably previously the functional requirements were based on the Breakthrough Use Cases and given the fact that the functional requirements probably don't cover all the domains, we think that they need to be expanded. So, as they evolve with further use cases later on, then the functional requirements are not encompassing of the totality of what the NHIN would be.
We also thought that there was still need for ongoing refinement of the edge and core definitions and what the aspects of the services provided there. Many of the functional requirements would have been more helpful if they had been business oriented because many of our people were functional looking at the requirements rather than more grouped in technical terms.
There was also a mixture into the requirements of system characteristics, business rules and design specifications, we felt. To give kind of a summary of the results of our review, of the 896 requirements in our review, of the 997, we felt that 98 could be considered minimum essential requirements by the federal agencies.
The summary is in a report on page 6 through 9. It summarizes what those minimum essential NHIN functional requirements are. I won't go into detail with them but you have them in the report. We also felt that on page 9 through 11, you can see where we saw the gap in the minimum essential requirements score based on the NHIN framework that we put forward and that is the gap that we saw shown.
There were some of the requirements that we had in the spreadsheets that were outside of the minimum essential that we felt were either duplicative or more policy oriented type of requirements. This is just a summary view of what they are.
I would like to in the report, though, highlight some of the specific high level gaps that we noted from the federal agencies. One is the requirements with regards to the federal mandates for security and privacy addressing items like FISMA, which is the Federal Information Security Management Act, how that relates to the NHIN.
Also, with regards to the delegation of access control and release of information to third parties, we didn't feel was sufficiently addressed.
Also to 508 compliance, which is for compliance with people with disabilities, potentially how they would be able to access information. We also talked about the issue of medication and e-prescribing wasn't addressed because it simply wasn't in the use cases. So, it was lacking also and role-based access control, particularly with regards to credentials for providers, looking at the identification of providers based on credentials.
Also, too, with regards to cross-organizational auditing, support for community health centers and safety net providers. Research and clinical trials is mentioned. We don't think it was adequately addressed by all the functional requirements and was sufficiently addressed and no other further detail needs to be brought out in that area.
Possibly with the use case in that area it would show more of the functional requirements necessary. Capture patient consent for release of information. Also, emergency access was not expressed adequately, such as -- I think it was mentioned, how do you break the glass type of thing in emergency situations and particularly also, too, with the issue of with regards to supporting the reporting of adverse medical events and how to -- both by the consumer and provider in that respect as part of the NHIN's work.
These are just some highlights. I showed the highlights based on our functional roles that we looked at because that is the way we conducted our initial analysis. In the report, though, we went to the NHIN's framework forum so you can see the long details that we looked at in the report for that.
I think that you will find that we also in our spreadsheets, you can see the individual agency's comments in detail if you would like to go through the 997 reports there and see the different comments, but we wanted to summarize them for you.
MR. SANKARAN: In summary, Federal Health Architecture would like the committee to consider using the information provided to understand the Federal perspective and include Federal needs. Also, utilizing FHA as a resource to collect Federal comments for future NCVHS in a joint activities. We are here to help you.
Again, thank you for the opportunity to address the committee.
DR. COHN: I want to thank you both very much. I actually really do like these longer documents. They are very good for airplane reading. Seriously, it is something where -- you know, it is 900, but it is not 10,000 yet. So, I really appreciate it. Thank you.
MR. SANKARAN: Simon mentioned to me like it is good to have it to read it after a glass of wine.
DR. COHN: Thank you.
Our next presenter is calling in. Kevin Hutchinson, are you still there?
MR. HUTCHINSON: I am.
DR. COHN: Thank you so much for being willing to join us. I am sorry we can't see you in person, but we do appreciate your willingness to participate anyway. My understanding is you actually have a power point presentation. I am going to have somebody go to the front here and run your presentation for you. So, please.
MR. HUTCHINSON: Okay. Thank you, Mr. Chairman, for the opportunity. I do apologize for not being able to be there in person today, but a nasty bug has kept me home today.
I want to quickly go through and highlight some of the things that are actually happening in the marketplace as we are seeing it today and weave into that the actual standards and function requirements that we see for both the edge systems, as well as the National Health Information Network.
If you go to slide 2, it is just simply to show who SureScripts is, for those that are not aware. We do have over 90 percent of the pharmacies in the United States certified on the network today and actually every pharmacy in the U.S. that is doing electronic prescribing is, in fact, on our network today. So, we have a lot of experience in how to bring these two worlds together.
In looking at slide 3, one of the uniquenesses of the company and the organization is that we are one of the few networks in the industry that does not supply an end user application. We are purely the network, purely a routing function, validation function between physician software vendors and pharmacy software. Today we have over 60 various different physician software vendors that are certified on the network today.
Going to slide 4, it is just intended to show you as e-prescribing has gotten a lot of attention, even most recently with the IOM report, it shows the types of messages that are, in fact, being exchanged between various different stakeholders and community pharmacies, both new prescriptions, refill authorizations, medication history, as well as formal eligibility checks.
Today we have the physicians, the RHIOs, the payers, live on the network and exchanging that level of information and hospitals for medication reconciliation are headed down this path as well. We have not connected into PHRs because of a primary concern that we still have over the level of process and standards there are for authentication. I will speak more to that in just a minute.
If you go to slide 5, slide 5 is really intended to directly answer more of Question No. 2 that was in your document, as opposed to what things in the edge system should be required. These are a lot of the things that we as a company are doing today on behalf of pharmacy and physician vendors in the connectivity world between these two environments.
Auditing and logging of all transactions process is very, very key as we have found where there has been question as to where a transaction originated from, that capability is there to audit and log all of the transactions or even what medications may have been ordered. There are a number of other things. Some people think with respect to the data that -- the standards that exist today, that everyone is on those standards.
As we all know, it takes different software vendors a period of time to be able to get to the next level of standards. So, we also have to do some data mapping and translation between versions of a standard and any edge system will have to do this no matter what standards are put out there. Software vendors will be at various points in time with their implementation of that standard.
I am happy to report and I am very pleased to see that NCVHS supported the move to NCPDP Script 8.1 in December of last year. I am happy to report that of the over 60 different physician vendors that are on the network, 80 percent of them have now implemented the NCPDP 8.1 standard and have recertified on the network and we expect a hundred percent of them to be on 8.1 by end of this year.
So, these are some various different elements that are specifically to the edge systems. Now, this is really targeted toward usually specific environments, you know. There are going to be different requirements whether it is a pharmacy or whether it is a hospital or whether it is a payer. There will be some various different requirements based upon the stakeholders that you are working with.
If you go to slide 6, it is just intended to show you what is happening in the industry right now is there is a variety of different ways that some of these RHIOs are being created. The RHIOs could be considered to be edge systems in themselves. Some are doing in a clinical -- a repository approach, some more just the master patient index function, others a full-blown record locator service, including the use of the master patient index.
We are seeing different architectures that exist as well. These regional systems, whether it be a regional hospital, a regional lab, connecting into these RHIOs, makes a lot of sense. Where we are seeing some difficulty is where we have national organizations like a national hospital chain or a national lab chain or a national pharmacy chain, who really has struggled to connect into a lot of different architectures.
If you go to slide 7, we are seeing the RHIOs being able to interoperate. I think most everyone is aware of the demonstration project that is going on through the Markel(?) Foundation, where the Massachusetts, Indiana and California RHIOs have interconnected and are able to share information across those various different environments. That could also be used for, you know, patients that are traveling across the country, as well as in biosurveillance and population health initiatives as defined in the region.
There is also some statewide prescription drug monitoring that goes on and in many cases, we have several different RHIOs in the same states, states like Florida or Texas or some of the larger states, we might see different networks being created within their own state boundaries.
Slide 8 actually is probably one of the more important slides to try to get my points across about the National Health Information Network and the edge systems. It is directly attributed to your Question No. 1 about the NHIN function.
As I stated before, you have these national organizations, but they have local establishments. So, a CVS is an example of a national chain but with local stores, the same with the Quest Labs is a national laboratory but with local laboratories.
So, they struggle with this idea of this national focus versus the regional focus and we really do see the National Health Information Network as playing a role between this national focus and this regional focus, whether it be hospitals, plans, payers, laboratories, pharmacies. The functions that they need to provide are really data routing and transmission, certification of the edge systems to make sure that the edge systems are adhering to the standards of NHIN.
Registration authenticating the edge systems, in other words, validating those edge systems and the data that is being shared or transmitted, as well as the record location, validation of the data, I mentioned before, and also even though an edge system is performing and auditing a logging standpoint, I think any system, any network that is transmitting health information should auditing and logging capabilities.
The real challenge here is at first hand experience, SureScripts is connecting in several different RHIOs right now, both Massachusetts, Upstate New York, Indiana and a number of other RHIOs, all on different architectures, where we are requiring 8.1 to be the standard to connect in those environments. We are not going to be able to connect in the hundreds of different RHIOs. There really needs to be an infrastructure, a National Health Information Infrastructure, where national organizations, where we may represent pharmacy access, can connect into an infrastructure that is connected into all of those RHIOs.
Today, we are going to continue down this process of connecting directly into the RHIOs, but we look forward to the day when there are additional standards or approaches to where we don't have to have so many different customized implementations on a RHIO by RHIO basis.
My final slide, slide 9, which directly goes toward Question No. 5, addresses what I mentioned before, an NCPDP Script 8.1. We are very pleased that physician vendors have moved to 8.1. We did give one year notice of the requirement to be on 8.1, which gave the vendors time to plan that implementation. I think that is something that the National Health Information Network needs to address as well is when standards are -- new standards come out or new versions of the standards that have been adopted come out, to establish the right time line for the migration to those standards is very important.
Otherwise, you are going to have a lot of data mapping, a lot of translation of data that occurs if the stake is not in the ground on when those new standards need to be implemented and put in place. The Scripts standard, as an example, will need to evolve if it is going to be a more interoperable standard. For example, where we may be sharing medication history with physicians today from pharmacies to physicians, it does not call for an ability to share medication history information from a pharmacy to a personal health record.
Now, one could argue we could use the exact same standard that is used to share it with physicians. The challenge is there are different work flow requirements and data that we have coming from physicians versus data that we might expect to come from personal health records. So, the standards have actually entered into an interesting area, whereas, not only the identifying elements that are part of the standard for the exchange of information, but even standardizing or dictating the type of work flow for how new prescriptions, refill authorizations, medication history and other information is to be shared and we need to make sure that we really limit that as much as possible to where it is not so limiting to work flow requirements.
One of my biggest points I would like to make today is around authentication. I have been on this bandwagon for quite some time about the fact that we do not have a good policy or good standards for authenticating patients, that they are who they say they are through the personal health records. We need some level of not only initial identification of patients when they gain their first ID and password. I know there is work being done on maybe a better rated ID, where we would be -- the National Health Information Network may establish a standard that if you have an online relationship already with a bank or another entity, you might be able to use that established relationship to be able to get access to your health ID, password and ID.
So, there are a number of different ways to look at it. Also, some have argued that cell phones or telephones where there is a confirmation that goes back in calling back the phone or using an IBR or sending text messages back to cell phones, but you would need to ping off of various different phone companies to make sure that that is, in fact, that person's cell phone and not one that is a bogus cell phone that was entered by the user.
So, there are a variety of ways to look at ways to do authentication, but I do think in the whole scheme of things, both at a RHIO level, even at a National Health Information Network level, that is one of the biggest holes that we need to be able to fill.
Finally, and I think I heard one of the previous speakers mention it before about HL7, CDA and CCR standards. We really do need to get those normalized and finalized into the types of messages that they will support and the exchange of that information is critical. We have many, many physicians connected into the network today. We could easily transmit messages between physicians because we are transmitting messages between a physician and a pharmacy today. However, there is not really a strong, well-accepted standard in the industry right now until we normalize the differences between the CDA and CCR.
So, Mr. Chairman, I appreciate the time that you have given me today and I apologize once again for not being able to be there in person.
DR. COHN: Well, Kevin, thank you very much. I am sorry you are under the weather. Obviously, we have seen you enough in person over the years that I mean it is obviously good to hear from you again.
MR. HUTCHINSON: Thank you.
DR. COHN: Kevin, I actually want to start with a question. I am sure others have questions for the speakers. I think it has been a wonderful panel just in terms of bringing up multiple different points of view.
Now, Kevin, I have often thought -- and I think you know of our long history of involvement and support on e-prescribing, that e-prescribing would be the wedge that drives everyone towards electronic health records. Now, listening to your presentation, I am wondering if e-prescribing is also taking the lead on the National Health Information Network. I guess I am wondering as I listened to your presentation -- now, obviously, this gets to be sort of a definitional question but from your perspective, is what you are doing -- are you really an edge system or are you really a part of the -- are you really one of the fundamental infrastructure pieces of the National Health Information Network?
MR. HUTCHINSON: Well, it is interesting that you asked that. I do get asked that quite a bit. You know, what are you evolving into? You know, we are owned by the pharmacy industry and my belief is this and this is no representation of AHIC opinions or anything else. My personal believe is that you are going to see -- I have a theory of birds of a feather flock together. So, when pharmacies come together because they have a common cause, they want to solve a common problem, you are going to have a lot more success in working with organizations that have similar issues to solve, whether it be hospitals or labs or pharmacies, notwithstanding the fact that you have a lot of local, regional health care providers that are not national in focus.
We will continue to stay focused simply on the pharmacy industry business for the time being and anything associated with improving that prescribing process -- electronic prescribing is a piece of that, but the way we see it is we are more of an edge system because there is a lot more than needs to be done with respect to sharing of lab information, sharing of referral information, being able to do a medical history look-up versus just a medication history look-up. That is going to require the use of a lot more standards and a lot more exchange capability than we have in our plans today.
DR. COHN: Okay. Well, I will mull over whether you really answered my question or not, but I do appreciate your comments. I think certainly no one would represent that what you are doing is the full NHIN as envisioned, but I guess I will continue to mull over my question.
Now, Harry, I think you have other questions?
MR. REYNOLDS: First, I would like to commend this panel. Each of you stayed on the subject. That was nice. I mean, you each had your own little flavor in there, but you stayed on mark. Thank you. Because we are trying to distill this down. That is very, very helpful.
A lot of it sounded the same. I mean, the categories that you listed, the functions that you listed, as I was trying to take notes here, it doesn't look a lot different.
Somebody asked a good question the other day and I will steal it and act like it is a good one for me. What do you think the five of you -- is there anything that you really disagreed with what someone else said because the way you have put this together, this is not a bad framework, you know, to start building thinking. So, I just am interested if there was anything anybody else said that you didn't think was part of the base or you thought was off base. I would love to hear it, just as your opinion.
Good. Silence is unanimous. Thank you.
DR. COHN: It is good that we are getting that, especially on the second day.
MS. DAVIS: To answer the question on the eight documents, they are listed on the top of page 15 of my document testimony. The one I left out was imaging, the most important one, imaging. Sorry about that.
MR. BLAIR: Kevin, are you still with us?
MR. HUTCHINSON: I am.
MR. BLAIR: This is Jeff. This is a question, to be honest with you, I wouldn't want to bring this question up unless you were part of this conversation because you are familiar with this as an issue that came up as we went through our e-prescribing standards recommendations. Laura, you gave us a list of gaps. So, in a sense, I am really asking for feedback from both Laura and from Kevin on this subject. Yesterday, one of the testifiers representing a well-respected consortium that is giving us ideas on RHIOs and the NHIN included in their recommendations -- and they really meant it. I wound up checking to see if they were really serious. And they said they felt that nonrepudiation was an important core function.
Now, Laura, when you gave us the list of gaps, you did not include nonrepudiation as a gap. Now, the FHIN(?) includes a form of nonrepudiation. So, No. 1, Laura, could you tell us why you didn't include nonrepudiation and, Kevin, I would like to hear your thoughts on the idea of the NHIN, whether it should or should not include nonrepudiation.
MS. TILLERY: Just to let you know, it is included as part of the security and privacy. We considered that as part of the FISMA mandate, federal mandate issue, as part of that confidentiality, nonrepudiation, authentication, authorization. They are all parts -- they are elements of that part of the security process. So, we do really think that.
MR. BLAIR: Kevin, can we have your thoughts regarding nonrepudiation as a core function of NHIN?
MR. HUTCHINSON: In theory, I don't disagree with the idea of nonrepudiation. I really don't because you could then without any hesitation understand that this is the individual as who they say they are. My concern is the readiness of the technology to be able to implement at an affordable level and in the health care avoiding error rates that might not be seen in other environments.
So, I guess my concern with it is we are making great progress in health care at this point and, you know, if we could stop and wait until we get the technology to be more of a less error prone, less expensive to implement to make it native inside of these applications and other things like that. But my concern is that is to slow down the momentum of what is going on at this point, although understanding that we still need to be cognizant of the security and privacy. So, in theory, I am not against it. I just -- we are still looking for a better way to implement it in such a way that it doesn't slow everything down or make it cost prohibitive.
MR. BLAIR: Thank you, both of you.
MS. TILLERY: Just one side, though. One of the thoughts on the federal side was also the need for multiple levels of security and multiple levels of authentication. So, we think that that is an evolving functional requirement over time, that the technology will become mature enough to handle that type of security process. So, we would agree.
DR. COHN: Okay. Maybe I need to ask you what do you mean by multiple levels?
MS. TILLERY: That would be the ability for -- based on your role, but also based on the type of scenario that you are involved in. So that it depends on like in the military by the DOD we have your unclassified, sensitive, confidential, top secret type of thing. So, there would be multiple different levels of security that would be placed on it.
So, for example, if you are -- if it is a very sensitive type of passing of information, you might have a much more tighter secure messaging standard than you would if you are just passing CBC results or something.
DR. COHN: Thank you.
Other questions?
MR. BLAIR: It isn't a question so much as, Laura, I just really appreciated your identification of the list. It was an excellent list and it really will be helpful. Thank you.
DR. COHN: Okay. Well, with that, I am going to give everybody a break before we move into our final session. Why don't we take about a ten minute break and then we will reconvene at about 2:30.
[Brief recess.]
DR. COHN: Our next session is really an opportunity for public testimony and we have a number of people who have identified themselves as wishing to give testimony. So, I want to thank you all for coming.
We are asking, obviously, in the spirit of this being public testimony if people would try to limit their remarks to around five minutes and we will try to ask questions -- maybe except for clarification, we will ask questions at the end after you have all had a chance.
Gary Dickinson is -- because he has another commitment afterwards has asked to go second. So, we will move him up and then he follows Russell Williams, Charlene Underwood and Mark Adams.
Obviously, we want to thank you for being willing to come and talk with us. So, with that, Vik, I think you are up first. Do you just have testimony? Do you have power point?
DR. KHETERPAL: I actually do have a power point.
DR. COHN: Okay. Please.
DR. KHETERPAL: And I believe there ought to be handouts as well.
First of all, let me begin by thanking the committee for allowing this time for five minutes or so to share some thoughts that I personally have. I come to you today as a clinician. I am trained as a physician. I haven't done anything like patient care in about 16 years, became an entrepreneur after an NIH SBIR-funded grant became an EMR product, which is now popularly known as GE Centricity and ran the clinical information systems business for GE for about three, three and a half years, leaving that about a year and a half ago.
Now I think I come with a slightly different perspective as a father of three and eldest son of aging parents with issues in health care and then you personally have a greater opportunity today than I did 15 years ago to interact with the very system I trained in, so, this being the health system. Some of my comments are really frankly more tainted by that than anything else.
I thank first of all Mary Jo for her clarity in doing the invitation as to what our remarks ought to be. So, I have four recommendations.
First of all is to emphasize the needs of the local health information organizations or networks, those that actually form at a local level amongst providers the ability to interchange information, the little n in the network of networks. If the NHIN is comprised of a network of networks, the little n is the efforts at the local level, which are the building blocks of the larger initiative.
The first recommendation, which I will go into more detail in a subsequent page, would be to emphasize their needs a little bit more than I think they are getting a hearing on.
Second is to potentially take a deeper look at the security of the RLS, the Record Locater Service itself, and how secure it is. We spend a lot of time and energy talking about securing the privacy and the importance of behavioral health records and HIV and other sensitive clinical data, but not as much attention, at least the dialogue doesn't tend to get into what about all the demographic information that will be resident in the RLS and the threat that may pose.
Third recommendation is to actually -- I think all the use cases, including my colleagues who we have talked about, the research community testimony, just in the last session, is maybe a possibility of beginning to distinguishing the NHI requirements and prioritization of them along the themes of care delivery, biosurveillance, PHR and research and I will share some thoughts as to why I think that may be helpful.
Finally, if there would be some opportunity for the functional requirements to include validation criteria for record linking effectiveness since that we believe is a core enabling technology that really everything else is built on.
So, the first recommendation, emphasizing the needs of the local health information network or local health information organization and broadly speaking, you know, with the HIT-board and some of the other things that I think Blackford and others talked about yesterday, there are 500, maybe 600 announced real initiatives around the country. We are aware of the excitement around that. Yet, most of them are at the baby steps. They are startups.
The four contractors that have been working on it have leveraged in the example of what Mark Overage was representing, a lot of great work done at Reagan's Reef, a lot of great work done in Massachusetts, great work already that was done previously in Mendocino(?). I guess the theme is that pulling all of these things together is obviously the mission of the NHIN, but most of these folks would tell us that it took a lot of energy and a lot of technical know-how in order to get to regional success, in order for them to be able to contribute in a meaningful manner at a national level.
So, our thought is that in the dialogue and particularly in the functional requirements if we were to go through them again, as some of our folks have done, to say which of these can be tuned specifically to assist local communities to adopt this, which of these standards could apply uniquely to them or specifically to them, such that they are in a better place to be able to participate in things like an interest null bridge or something of that nature.
It seems in my personal view that there is not a whole lot of attention or particularly time allocation to the needs of that local environment. So, three specific recommendations. Develop some sort of requirements, specifically SNO in the core environment, the core of the system of the NHIN. Maybe encourage HITSP or something like CCHIT to accelerate the focus on interoperability for EHR. We look at that 2007 efforts that CCHIT has. That is sort of the bottom up approach that will allow the EMRs and other things that are being adopted at a very local level to be able to populate the local health information exchanges so that they can participate and enter SNO bridges to effect NHIN.
Finally, maybe sponsor work to define intermediate stops along this journey towards NHIN, a more incremental approach to say what might be the immediate next step if somebody is successful in a locale. What does a reasonable success look like? What are the functional requirements that sort of graduate an entity from one to another.
A set of sort of animation slides which show up as one printout. Choice point, data loss awhile ago, followed by the -- of the records that card systems lost about a year and a half ago. Then something happened up in Providence, Seattle-based health systems, 365,000 records and then the most recent, of course, in the Beltway. It gets lots of attention as the laptop with, you know, 26 million veterans information.
Our takeaway from this is that demographic information is exceptionally dangerous. While clinical information release some issues around privacy and security are obviously of importance, as I suggested before, the current real threat seems to be aggregation of demographic information that includes stuff that identifies people as who they are. That is where identity theft, financial risk and other things live and, frankly, that is the risk that has been realized over the last little bit, over the last few years particularly.
It is a particular concern as you analyze this and project the success of an NHIN because most Record Locator Service design as contemplated are centralized in primarily centralized models. Although folks speak to the ability to have a federated RLS, frankly, even the four prototypes that are being currently contemplated would be centralized. So, our thought there is that maybe the recommendation here is that the core functional requirements should address a need to have a blinded secure RLS, one that withstands the obvious vulnerability of a large store of demographic data sets, which if wildly successful may comprise a vast majority of the citizens of this country and all the really confidential information that goes into affecting identity theft.
There has been some great work done in Australia with linguistic techniques, such as bi-gramming, that allow -- you know, Shawn Grannith and Mark Overage have some exposure to this stuff. It has not been done in production in the U.S., but we have actually tried this out, so to speak, in a lab and affected it at a couple of communities. such that you can actually have a blindfolded Record Locator Service. As a holder of that service, you can do linking for citizens without ever knowing what the underlying name and address were. You basically have access to hash(?) -- so this is inherently a more safe, secure environment.
This not about encrypting, decrypting stuff. It is about being able to have a bank vault system, whereas, the operator as a bank, my safety deposit box, frankly, is secure because I hold the other key and even disgruntled employees, anybody else, they really do not have access to that. I think there are techniques of this nature that ought to be seriously explored as part of the core requirements of the NHIN.
Very specifically, some examples of that are listed. I won't go into them here. They are in your printout as to how n-gramming techniques could affect that.
A third recommendation would be to actually, as I alluded to before, separate the care delivery use cases from biosurveillance, PHR and research in the functional requirements. Some of this was borne out maybe in a very vocal way by the UHIN, JAN(?) and I think folks, Jack, spoke to it a little bit. The idea here is both for business models, that is where the business model justification lives is at the local level.
From a citizen's perspective, if you would look at the Harris and RAND studies and some of the other data out there, if there is one reason that citizens of this country are willing to withstand what they think, what they believe to be potentially at a higher risk for privacy, it is because it would enhance clinical care.
So, our thought is not necessarily as I think your recent submission to the Secretary, that somebody actually suggested forget all the other stuff. Just focus on care delivery in the first go-around. I am not suggesting that we throw all that out, baby with the bath water, but minimally to actually look at the functional requirements along these four themes and ask the hypothesis to say how would I prioritize this if I wasn't doing it for biosurveillance. How would I prioritize this if this was not for PHR? How would I do this if it was purely for clinical care?
Our suggestion is that you would end up with potentially different functional groupings and prioritizations as to what should formulate core requirements for the functional requirements versus not. And they may clarify a path that is more actionable than a super set of all wish lists.
Final recommendation 4 is, again, potentially too detailed and potentially not really a functional requirement recommendation at all, which is to say, you know, if we are going to get to a specificity of one in a hundred thousand false positives, that the NHIN functional requirements contemplate how good will the sensitivity be.
All four of the contractors when I asked that question a few weeks ago at the forum said they are not actually officially studying that as part of this prototype. So, we really don't have a path right now that we are on through the course of the experience collectively that says, hey, when we try to achieve on some of the shall we say the fulcrum around which a lot of this Record Locator Service has to live, what do we actually achieve since we are not formally studying it? Part of the reason the study is very difficult as an entrepreneur outside working in this space is there is no gold standard annotated data set of linked records that I can subscribe to and say I have come up with really something cool or good that works. Let me test it.
I don't know how to go test it. So, either again through a HITSP or a CCHIT, it is not really a certification issue, but really the work to sponsor, to authorize, to fund an initiative, to create this gold standard annotated data set that could be used by all participants that are working towards this mission.
That was my last recommendation. Thanks.
DR. COHN: Vik, thank you very much.
We will try to hold all the conversation until we have heard all the presenters. but very interesting.
Gary, you are on next.
MR. DICKINSON: My name is Gary Dickinson. I am director of health care standards for CentrifyHealth, which is an emerging PHR vendor. We essentially took the list of functional categories that you supplied and came up with our own rankings for those. For each of them, we identified or for many of them anyway we identified particular things that we thought were particularly important to consider. We did not do an exhaustive gap analysis, simply not time for that. But appreciate the fact that others have.
Basically, we want to ensure just kind of briefly skimming this list because I have a number of slides, basically, audit and logging needs to include traceability, which is end to end, at least in the space of source to receiver. Authentication needs to ensure that we are identifying edge systems as they communicate within the network and that we have authentication of the source and authorship of records and data that are communicated across the network.
Authorization needs to include not only authorization for access to individual health records, but authorization to access to system functions, authorization for access to particular data content of the record. Confidentiality is ensured by many of the other functions that are identified in the list. So, we won't belabor that.
Credentialing, we did here is to include not only individuals but also to ensure organizations are appropriately authorized and registered as being appropriate partners for communicating systems on the -- communicating organizations on the network and then, of course, communicating systems also would need to have the same level of authorization and registration for their participation in the NHIN.
Assuming that each of those would also not only have a discrete identifier for them, but would also be classified by their role.
I am continuing on. I am now on slide 6. I don't think there is anything particularly astounding in any of this. I think I will move directly on to the recommendations for standards. We believe that the HL7 -- I am now on slide 9 -- HL7 EHR system functional model is a key component of standards that should be considered as part of the NHIN of the functional model specified as functional characteristics of EHR systems, which includes a set of interoperability functions. It is obviously the framework for CCHIT and their certification of the EHR systems.
It is now a normative standard, which is just going to ballot here next week now at the membership level ballot. So, hopefully, this will be the final round of ballots for the functional model as a normative standard. An emerging standard in HL7 -- I missed a bullet point here -- is the EHR interoperability model, which specifies interoperability characteristics of EHR records and is complementary with the EHR system function model. It is now a draft standard for trial use, which is also going to ballot use here this next week.
The bullet that I missed on this slide was that this interoperability model specifies have a common EHR record unit. We will talk about that here in the upcoming slide.
Also, a few standards to consider is ISO 21089, which is trusted end-to-end information flows, which specifies persistent health record and key points in its flow and lifecycle, including origination, amendment, translation, verification, access/use, transmittal and receipt, anonymization, aliasing, archiving and so forth.
Basically, what we believe in terms of network functionality is that we have already defined through the EHR system functional model and through the efforts of CCHIT a set of criteria for the systems at the edge or at least for EHR systems at the edge. We believe that the network is -- the network functionality should be very complementary with those functions of the edge systems on both sides, assuming that -- in a simple paradigm as we have outlined here essentially of a source system. You have the network in the middle and you have a receiving system and ultimately that the functions of all three in that sense, point to point, must be complementary.
So, we believe that there are basically four classes of NHIN and interchange. The first two are traceable to a persistent source of information, which would typically be the originating system for a particular health record. So, those two are the individual health record as traceable to a persistent source or an extracted subset of that health record is also traceable to that persistent source.
We believe that other things would be communicated across the network, which may not have that characteristic, which may not be traceable. We also believe that messages are fundamentally transient interchange artifacts and really do not appropriately play the role for persistent, indelible exchange of information from source to ultimate recipient.
We think that this can all be simplified in a very straightforward manner, as has been identified in the HITSP AHIC use cases, everything -- the use cases all resolve down to an action. That action is the occurrence of some event in health care. That action requires an action record, which is persistent evidence of that action and that action record is then interchanged either as a persistent record in and of its own right or an abstracted subset of that record, which yields an energy pattern, which looks something like this, where the originating system or the source system originates and retains the persistent record.
That record then may be persistent across multiple hops if you will to additional systems, which also retain that persistent record in its original, indelible and unaltered form, which can be authenticated in all cases. There may also be cases where the second or third system may use an extracted subset of that persistent record. But there really are only two cases in terms of traceable records back to the source.
I would suggest that our standards focus going forward needs to be much different than our standards focus in the past. In the past, particularly in HL7, we have focused on what happens at the back end. Messaging, point to point messaging, using -- or point to point interfaces using transient messaging. We really need to move rapidly to a persistent legal health record and by definition that must be something that is created, originated, retained, in the source system at the front end. It is not a back end artifact. It is a front end artifact, which has been passed by the back end interface from system to system, where systems may choose to extract only the information they care about from that record, but at least there is a path for that persistent record from its point of origination to its ultimate point of use.
Again, I believe that our standards focus needs to be front end focused and that implies, of course, that standards must become internal to applications and are not simply back end artifacts. I think that is a crucial leap for this industry to move forward appropriately.
Thank you.
DR. COHN: Gary, thank you very much.
Our next presenter is Russell Williams. Thank you for joining us.
MR. WILLIAMS: Thank you. Good afternoon, everybody. My name is Russell Williams. I am speaking today on behalf of the American Health Care Association and the National Association for the Support of Long Term Care.
I am a nursing home operator in Atlanta, Georgia. We operate three non-profit nursing homes. I like to think that in addition to speaking on behalf of these two groups, I am also speaking on behalf of all of our patients that we take care of everyday.
I about three years ago recognized the need to move in the direction of electronic health documentation for the improvement of the care and service that we expect our nurses and our nursing assistants to deliver everyday. I recognize that the checklist, the paper systems that they were using at the end of their shifts just was not sufficient to address the very detailed needs of our patients. So, we started exploring all the different vendors that were out there and we implemented this system.
I am here to tell you that it has been wonderful. It has been a lot of hard work, but our patients today get better care than they ever have before. Our CNAs have Palm Pilots that address what specific issues that they need and when they need them. This has improved our satisfaction, the quality of life of our seniors. To me that is the most important thing.
So, I don't think that we are unique in our approach to wanting to take care of our seniors. It is just that we have to give our staff the tools to do this work. That is simply something that our country doesn't have right now. Now, we have done our part, as far as I am concerned, my little organization in Atlanta. But when we send our patients to the hospital, their information doesn't flow. They don't know if they are allergic to a specific medication and they are starting all over again, every single time. So, we are firm believers in our operability and we wanted to make a point today with this illustration of our group. It is important that long term care is part of the design of this NHIN, not something that we are assimilated into after it is already made.
That being said, we did take some time to look over these standards, the functional requirements. I thought I would just go through a few of these ideas with you right now. At a minimum, adoption of a common set functionality that allows nursing facilities to exchange information with hospitals, doctors when transfers occur. This exchange must be handled in multiple ways, including rural areas by dial up and by fax.
At a minimum, this connection for the facilities needs to be secure. It is a common theme I have heard all day. Authentication. Important.
A system must be designed to accommodate a nursing facility environment where nurses and nursing assistants provide the hands on care, the bedside observations and complete the care status reports. At a minimum, the NHIN best serves as a pointer system, allowing for the capture of the most recent information.
And at a minimum we are concerned that there are being too many "shalls" in these functional requirement implementations will become more or less cost prohibitive for long term care operators to become involved in this network. So, we want to make sure that we are not trying to create something that is a maximum.
The two examples of these maximums were the flagging new results in EHR. "New" is a new term that must be defined in great detail in providing around-the-clock care to long term care residents. Trying to flag every report and every little change is not possible. It may take more sense for long term care to submit information only when a resident goes out to the facility for care, hospital or ER.
"Shall" may be too harsh of a requirement in this case.
At a minimum in the data transfer area, it is important that appropriate standards be selected and that those standards are disseminated to interested parties for implementation in the edge systems. Long term care in this country, we are projecting to spend $128 billion this year to care for our frail elderly in the nursing homes.
In 2015, that cost is projected to grow 60 percent to $217 billion. For long term care, people that are working in these facilities and the technology folks that are working there, they need to be considered as this is being designed. It is my personal believe that that $217 billion that is projected will be drastically reduced if we can come up with this system and have long term care involved in it because I do believe that that it not only improves patient care, but I believe ultimately it saves money.
Long term care profession, we enthusiastically offer our HIT experience to you to ensure that the NHIN becomes a reality. The long term care will fit into this system in a comprehensive way to improve patient care.
Thank you very much for your time.
DR. COHN: Thank you. Actually it looks like you had another recommendation specifically also --
MR. WILLIAMS: Actually we did. I kind of skipped that over. This was referencing the multiple language support specified and displayed by the user. Without qualification this is untenable in long term care, we believe. We question whether this can ever work. Questions regarding languages and who translates. The translation software with medical spell checkers struggles currently with English. The cost of compliance in terms of time and dollars we believe is beyond our means. "May" might be a better way of saying this instead of making it a functional requirement.
DR. COHN: Okay. Thank you very much.
MR. WILLIAMS: Thank you so much.
DR. COHN: Mark Adams -- actually I am sorry. Charlene.
MS. UNDERWOOD: I am going to actually -- I introduced myself this morning. I will try and keep this timely because I know you are on a schedule. My name is Charlene Underwood and this time I am actually presenting with a Siemens hat on. Siemens Medical Solutions today is about 13,000 people in the United States. Again, it is a global company and we provide medical imaging technologies, health care information systems management consulting and support services to nearly 12,000 health care providers.
Again, on the focus of my testimony today and you should have two handouts. I am not going to impart to you all the detail of my second handout, is I have got a high level piece, which we will walk through fairly quickly. I had actually included a lot of detail because my message here today is fairly simple. We are not operating in a green field. There has been a lot of commitment and investment on the vendors in this industry's part, as well as our customers in implementing information systems for many, many years. There is a lot of experience I think that can be brought to the table in helping solve and address the NHIN area. What this testimony will do and what the documentation does more so is really just correlate the parallels, what are the requirements from the NHIN to what is actually happening today in trying to integrate and share information across health care enterprises.
So, when you look at the goal of the NHIN, which is to foster widely available services that facilitate appropriate, timely and secure information of health information, there are many similarities to trying to do that in health enterprises today. So, this information I hope will provide the opportunity to leverage the lessons learned and that is what is documented in the detail of the information, as well as suggest that the NHIN efforts should focus in experience on areas with theoretical benefit, perhaps limited experience and collaborate very fully with the HIT industry for areas where there is clear overlap and experience.
I think you saw that in Kevin's example, when he explained some of the experience they had had with SureScripts. To that end, I am going to really talk about lessons learned, but I am going to if you will put your David Letterman hat on because we are actually going to do it in a way to kind of wake up the afternoon, if you will. We are going to talk about ten reasons why and we are going to go on the positive, why building a health information network is achievable. I am going to share with you some statistics, some evidence of why we know this.
First of all, importantly to be successful, we have to integrate data exchange into the work flow. So, to that end, most of the vendors today have adopted standards like C-CAL(?), which enable data sharing at the desktop. They have adopted concepts of portals and then in addition we have implemented and, again, we can't forget the financial industry in this picture, you know, processes to really exchange eligibility information. For example, we provide a service, which supports eligibility, which processes over 12 million eligibility transactions per month and these today are fully integrated with customers registration, scheduling and admission systems.
So, this capability is available already. So, again, one of the key requirements we believe of supporting this kind of a network and there is evidence and experience that you can leverage in defining what is possible. We do know how to match patients. Another example of that -- and I will give you two evidences of that -- No. 1, one of our products is a product which is an EMPI and in that we have over 106 million patients, which represents 37 percent of the population in the United States. So, we have done this a long time. So, there is a lot of experience.
It is not just Siemens. It has initiated a lot of other vendors, who have had this experience and we have to match and manage and there is a lot of experience there. This brings a lot of value and, now, unfortunately, some of those 37 percent are dead because patients that go to the hospital die. But those are kind of the numbers we are using.
One other piece of evidence, you know, to that end is that we are also able to with our eligibility services -- and I think this is, again, another great parallel, we process over 12 million real time transactions per month and 99.9 percent of those inquiries for eligibility are successful, again, matching algorithms that are working today in both an EMPI sphere as well as the eligibility sphere.
We know how to exchange data to and from multiple systems. Incredible investment in the industry and the concept of interface. Siemens itself has libraries of model interfaces again. So, there is great experience in doing this. In the eligibility sphere and I think you heard in Kevin's presentations, but we link to banks, we link to payers, we link to multiple kinds of hospitals, again, ability to leverage that experience.
We know how to provide high speed, available, reliable communications and, again, just the example of being able to instantaneously provide eligibility transactions for over 12 million inquiries per month on line with end users gives you the example of the kind of performance that is available. Again, performance is going to be a key here in terms of the success of NHIN.
Likewise, it supports your requirement in terms of supporting high volume, real time transaction processing and data exchange. Actually on point 4, this one, I hesitate to put on the public record, but we do have a very secure network, which has terabytes of data, you know, has over 500,000 end users that access the system and is fairly fail-safe. We have not had an intrusion.
So, it is possible to achieve, you know, kind of what Vik was saying. It is not that you don't want capabilities, but our experience is you can learn from in the industry. They give you evidence that you can do that today.
We do know how to integrate data of varied quality, granularity and consistency. Again, huge investments in concepts of vocabulary engine, on customers
-- a lot of time normalizing their data to help move in that direction. They have done that over the last decade. The example here in terms of the HDX services is that if you are going to do these inquiries, again, you have a high percentage that are successful inquiries. And I have one other piece here.
As we process these millions of transactions each month, the acceptance rate of these transactions by the person receiving them is over 98 percent. So, again, good experience that demonstrates in the financial community if we model some of that and, again, you have got -- there is evidence that you are able to accomplish this network.
Perhaps one of the most important things is to know how to collaborate with other stakeholders to improve operability. A significant investment by the industry -- like IAG and with other stakeholders to make this happen. We know how to accommodate local, regional and national standards and policies. Again, we operate nationally. We operate globally. We have to be able to do this.
These last two come from our customers. We had a focus group on Tuesday morning and I said I was testifying. So, they asked me to deliver really two messages. This is perhaps one of the most important ones I can bring to the table. There is a clear recognition by the providers in our industry that the financing and delivery of health care is in for a major change. We want to move to paying for quality.
So, to get there in the very interim term as we move toward, you know, these new models of health delivery, they don't want to build anything into the NHIN that perpetuates today's model of health care delivery. So, their recommendation is keep your first phases simple. Keep it incremental. We have an example of one of our implementations, which is implemented secured messaging. They share information among 500 physician practices. Saving those physicians $6,000 per year by a physician. Again, secured messaging, it is open, innocuous, whatever EHR. It automates manual processing, attacks this simple stuff in terms of removing -- you know, making it convenient, as well as the productivity issue.
So, again, when I look at that implementation to me, it is a start-up NHIN. It doesn't do everything that we have talked to, but, again, it is grass roots. It addresses the local levels. It is very convenient. We invite you to take a look at it.
Lastly, this again came from our customers. They say, well, okay, financing is the biggest issue but, you know, I don't have to ask for building an ROI for a CT scanner. I mean, why -- clinical information, if you will, is just a tool to improve quality and we do see it in the future becoming an expected standard of care.
So, that was kind of their last recommendation. So, I guess funding is a huge issue there. This health information exchange they view to be as a public utility and we need to look at it as becoming an expected standard of care.
The last couple of slides -- and I am not going to spend a lot of time, but as we kind of model what these architectures look like, so you kind of look at -- and I think this parallels the past presentations -- what the enterprise looks like. So, the top is the patient centric view and the bottom is all the departments and facilities they get connected to. That is the work we have been doing for the last 10 to 15 years.
And our customers have been doing to integrate -- if you look at the regional health network, again, you will see a lot of the different pieces and you will see consumers attached to that regional network and perhaps some of the lower hanging -- some other facilities that can't afford more sophisticated attachments to the NHIN. So, again, you start to see some of the same capabilities in the regional network.
Then if you move off to the NHIN, again, network-network, you are going to see some of the same capabilities. At that point, do consumers or perhaps some of the rural facilities attach directly to the NHIN. So, again needing things in common.
Lastly, I just wanted to convey that we do offer -- and I mentioned earlier this integrated health EDR network. I gave you some of the statistics. Again, other vendors offer these same type of capabilities. I encourage you not to lose sight of the success that has been gained in trying to support EDI and data exchange from the financial venue and see what you can do to leverage that as part of the NHIN effort.
Thank you very much.
DR. COHN: Charlene, thank you very much.
I think our last presenter is Mark Adams.
DR. ADAMS: Those of you who know me know I am notorious for not taking much time talking about things. So, I will do my best today.
I am Mark Adams. For those of you who don't know me, I am the project manager for the caBIG project out of the National Cancer Institute. I am a senior associate at Booz Allen Hamilton and I am a bioinformatics person.
I am here really to discuss how we have been implementing within the caBIG project a multi-site, multi-institutional research network for collaboration and coordination and how we can both make use of but also perhaps show the way a bit based on the work that we have done to the NHIN project. I do appreciate having the opportunity to present to you.
caBIG or the Cancer of Biomedical Informatics Grid sports coordination and collaboration among almost a thousand participants spread over more than 50 sites throughout the country and now increasingly internationally. Software developed as part of this program is open in many different ways. It is open source freely available. It is built to open standards, a variety of open standards and we are involved in those committees. It is openly developed. The software is developed within the community, both commercial and academic sites and it is federated. It is open source, freely available.
It is built to open standards, a variety of open standards and we are involved in those committees. It is openly developed. The software is developed within the community, both commercial and academic sites and it is federated. It is open to a connection without having the necessity of a single centralized site.
It is federated among often existing systems. This picture illustrates how diverse the group is, both geographically, we have got a map with a picture of participating centers spread out throughout the country and also it is a set of photographs, which illustrates the variety of types of activity, which are carried out within the context of the caBIG project. This range of activities is illustrated in this slide, basically ranging from clinical trials activities, a collection of clinical data, through the management and collection of the tissue specimen's derived from that, proceeding through analysis, laboratory analysis, both conventional and high throughput molecular biology and ultimately the correlation of the results from that analysis back with that original clinical data collected at the beginning, closing that traditional bench to bedside loop.
The intent here, obviously, is to create an opportunity whereby data collected in any part of this system can be correlated, collaborated and ultimately fed back for the use of clinicians, patients, clinical researchers. This, we believe, is relevant to this group. It is our hope that we would be able to leverage and participate in the National Health Information Network and allow us to carry out this diversity of activities within the context of that network whenever possible.
caBIG involves a large community, as I had illustrated before, but this community includes not only the folks you might expect, the large universities, universities like the University of Pittsburgh, M.I.T., Harvard and others, but also government agencies, such as the National Cancer Institute, FDA and others and then finally companies, both large and small, IBM, Bellows and others. Again, a very large community and, again, somewhat illustrative of I think what the work that is going on here, it is an attempt to take a very diverse group of communities and allow them to communicate with one another in a consistent way.
The caBIG architecture, the approach that we have taken is federated, again, based on our needs, but it provides the means and as was discussed yesterday, by making use of tooling like standardized vocabularies and standardized data elements, an approach that makes use of mapping to those vocabularies and data elements is a way of providing access to a variety of information and existing systems, I think is something that is, No. 1, illustrative of what may, in fact, ultimately go on within the NHIN, but also we would like to see the networks, which evolve from that in terms of our requirements be able to support this kind of federated transfer of meta data.
As an example of how this coordination takes place, again, yesterday, for those of you who were here, there was quite a bit of discussion around this meta data modeling, standardized data models and so on. We have been working closely in supporting and developing an expert group to develop something called BRIDGE. The BRIDGE Project is an effort to develop a shared meta model for clinical research, which can bridge a range of existing data models and provide a mechanism for interoperability among systems built using those data models.
These data models include some of the systems that we have discussed here today and yesterday, including HL7, C-DISK and others. We do think that it is this community of stakeholders approach, which doesn't force the group to select or elect a particular data standard, but sometimes can be allowed to select a set of standards, which support the range of activities and then create a meta data model that can provide interface between those. We believe that this is a reasonable approach and it is one based on the idea of shared semantics rather than the idea as we talked about here, kind of a dig out and replace and this semantic foundation again is as I mentioned allows messaging to be passed between the variety of different systems.
This BRIDGE model and, of course, this is just for illustrative purposes, this is actually a picture. If you could zoom down, you could read it. This is where BRIDGE is today. BRIDGE, as I mentioned, is based on the HL7 V3 rim and based on the C-DISK. It has a variety of contexts ranging from tracking, authoring, statistical analysis, recording and transmission and protocol design and so on, all of those functions being reflective of poor clinical trials activities admittedly, not necessarily for obviously, the delivery of clinical care.
These lead down or drill down to a set of functions -- on the Nationwide Health Information Network. One of these, just highlights -- we have written testimony, which I will provide in the next couple of days, which does exhaustively go through the list and analyze that in light of both what we have done and what we anticipate we might need. But just the top lines of some of these, we believe that the NIH -- should support core functions, which provide the means for operation of biomedical research. We would hope that it wouldn't exclude that as a fundamental use case. We believe that it is of interest to provide for secure and robust transmission scientific data and sometimes including fairly high band width data sets.
This has obviously been encountered in these discussions around imaging, but similarly things like gene expression profiling and so on are actually quite large and may in the future increasingly become part of clinical care, at least in cancer. The NHIN platform should allow for the establishment of system based on services or architecture as this was nicely discussed yesterday. The NHIN should leverage the BRIDGE meta model or something like it as a standard means of exchanging relevant clinical trials related data and as a means maybe of not being forced to elect between two competing standards, but a way to bridge standards that are deemed necessary for success.
Finally, NHIN can take advantage of the prototype establishment that is in caBIG of services that provide the semantic interoperability, even as a demonstration. So, as you start to think, as it was implied yesterday, about the development of these standardized meta models and so on, we offer the systems that we have built at least as a prototype that demonstrates that that can be done.
This leads me to my final slide. What is the future here? We have some commitments. We are going to continue to participate in this insofar as you will continue to let us, but the caBIG program will also leverage wherever possible the infrastructure that you develop and deploy. caBIG has a rule of living off the land. We try to make use of things that are developed in the community whenever possible. We try not to invent things. Members of the caBIG community will integrate their software. We have already got a number of groups here, who are also participating with caBIG and I think particularly important is the early phases of the project, partly because of its nature and biomedical informatics, caBIG tends to be kind of at the edges of the periphery.
We encourage you to take advantage of those folks who were pioneers to test early developments in deployments. They have experience doing this. The NHIN is invited to participate in caBIG's open process in whatever way is possible and appropriate. The BRIDGE is the most obvious place where representation from this group to that group may be appropriate. It is to foster these close relationships within these groups and to ensure that overlaps in development are closely coordinated. We are all trying to do the same thing here.
Finally, NHIN is encouraged to make use of any of the caBIG tools that are useful for the achieving of your goals. Again, they are all open and readily available. We would encourage you to look at them whenever possible.
Thank you for the opportunity to testify.
DR. COHN: I want to thank our presenters.
Do people have any questions for the presenters?
MR. HOUSTON: Having been involved in caBIG, it is an interesting project and I know that we have had a lot of discussion, some of us had at lunch today regarding how thin the core is and I know that was one of the discussions in caBIG was almost making the core almost nonexistent.
We sort of started talking today and we said it is almost like caBIG is sort of on the edge of NHIN. Did you sort of perceive that to be where caBIG falls also?
DR. ADAMS: I would agree with that. You know, it is interesting. caBIG I would regard as a system that more or less thins the core out to the point where it almost is nonexistent. There are a few obviously core services that will have to exist, especially in the context of things like we are talking about here, resolving a unique patient identifier and so on. But for the most part, yes, an ideal situation for caBIG would be to live at the edge, provide these research services but then be able to make use of some of these core services like unique patient identifier when they are provided by the NHIN.
DR. STEINDEL: You just mentioned that caBIG has established a set of -- focused down on a thin core and established a set of functions. You just mentioned one. Are there any others? I assume there are.
DR. ADAMS: Yes. Again, this is something we go back and forth. Given the nature, as you saw one of the key elements of the caBIG's federation, one of the things that we typically struggle with are when there are things that cannot be as we believe abstracted into a federated set must necessarily live within a core. Security management is one. We have been discussing quite a bit about how one actually effectively and truly federates security, particularly authentication and authorization of multiple systems without having a single core accepted registrar.
One way we have gotten around that typically is to say there is obviously a necessity for our services, certification services, but there may be multiple vocabulary services and common data element services that currently exist at the NCI. They are currently for all intents and purposes a core. Now, it is the intent of the program to provide for federation of those transmission and provision of standard vocabulary and standardized data elements, but for now those are three that we talk about a lot. There are others.
DR. COHN: Other questions, comments?
We want to thank our presenters. These are obviously brief reports, but I think certainly help flesh out and get us thinking about other ways of looking at all of this stuff. So, we want to thank everybody.
Now, I know we are second day mid afternoon, tough time to be having conversations. I suggest we take a five minute stretch and then let's get into the discussions of next steps.
[Brief recess.]
Agenda Item: Workgroup Discussion
DR. COHN: I don't know whether this is going to be a long conversation or a short conversation, but we ought to at least open the floor to the members of the subcommittee and workgroup to sort of see where we think we are at and then we will sort of talk about next steps and plans.
Certainly from my perspective, I was heartened by that there is some -- certainly some direction and unification used by many in the industry, which I think is very helpful to us. It is really not so different than I think what we thought about in the original draft sort of framework that we put together.
So, I think it is good to know that we need to improve it. We need to refine it, but we are certainly not far away from where we need to be. At least that is the view that I came with from the last day and a half. But I am curious about what other people think.
DR. STEINDEL: Simon, I agree this was really a very fruitful and interesting two days worth of information that was passed on to us in discussion and everything. You know, I have seen some things in the discussions. One of the questions that we have had among the ad hoc workgroup in framing this thing is how to set some guidance for how we are going to think about it and set our reports.
ONC has asked us to stay out of certain areas, which I think is rightful because we are not -- because I don't think anyone is really prepared to make statements at this time on architecture of the NHIN. We don't know enough about what it is doing and what it should do to make real statements in that area. We are definitely not charged with going into the policy area, the other areas and doing that. So, I feel it is very important. But without having some structure, I think it is going to be difficult to frame the report and I found two what I consider to be relatively trivial points of conversion that I have heard from all the speakers.
I hope this doesn't sound too trivial but I think it is going to be helpful in framing the report. The first one is the NHIN is a system of systems. That may sound trivial but I think it is very important. Everybody has talked about the concept of multiple things being hooked together. So, I think we have to conceive of it as system of systems.
The other thing that people have told us is these systems that are going to connect have varying degrees of sophistication. While those seem trivial, I think they are going to help frame a lot of what we discuss, talk about and put down. I would like that, if there is no objection, I would like that to be accepted as some type of framing mechanism.
MR. BLAIR: Could I suggest as part of that framing mechanism because I think there is going to be more -- Steve has started us off but I think a good way to phrase this is this is our assumptions that we are putting in. That way we are not saying it has to be this way. That is why we are not winding up making policy statements or architectural statements but the set of working assumptions upon which we can achieve consensus and thereby start to articulate the minimum functions.
DR. STEINDEL: I think that is a good clarification, Jeff.
DR. COHN: Comments? Stan.
DR. HUFF: I agree with those as framing constructs and I would go on and say that my sort of assimilation of the testimony and the other things comes down to that and actually probably, you know, the final presenter was sort of where I was at in the sense of it got so thin it is almost invisible there in the middle. The only thing that is maybe flowing in the middle is, in fact, just secure transactions on the Internet. The whole thing just represents software components in systems. Those systems could be part of, you know, a health care organization, a provider organization, a government entity. So, they are not -- you know, you are not forcing roles of particular organizations relative to how they participate in the network.
It is really a set of standard software, functions and services that can be deployed in anybody's system and if you adhere to those services and those interfaces, you can participate in the network. So, I can see that is troubling in some way but --
DR. COHN: Maybe I was looking a little troubled as you were talking about it. I think I almost agree with you. There is fluidity here. However there are things, the thing with the Internet is not -- you use the Internet. You connect to it and all of that, but you don't maintain and have the Internet at Intermountain Health Care.
So, I think we hear from caBIG that there were actually things that they did consider to be the core. Now, not a lot. I would absolutely agree with you about that, but I do think that there is some distinction there but not a -- it is not a hard line. It is more fluid.
DR. HUFF: There are a couple of things more that I would say. I am going to have to go to a conference call. That is why I am trying to fit this in.
So, what that means is that one of the primary roles, I wouldn't say necessarily the primary, but a primary role then in creating this is, in fact, creating the standards that allow people so that you know what you have to pay to play in the game. I mean, with Internet, you know, you have to -- again, you don't have the Internet, but there are defined standards about how you can connect to the Internet, you know, how you buy -- what kind of hub you need, other kinds of stuff like that. So, the primary role, I think, of the government or of the national organization is setting the standards that say, you know, how this can be done.
So, we are helped in that in that, you know, the standards and implementation guides should be approved by HITSP. I mean, that is what their job is. That is why they were commissioned. We could say maybe it should be somebody else, but conformance testing and knowing whether I am actually qualified to connect, you know, should be the responsibility of CCHIT, which is their job as testing whether people can plug in there.
Another sort of founding thing is that we are not talking about policy and one of the reasons is that policy is going to change over time. So, these things should be constructed in a way -- the systems basically that participate should be constructed in a way that it is easy to implement policy and data changes because that is going to -- you know, the kind of data you are sending, the kind of data that is of interest, the policies of the government are going to change over time. So, you don't want anything in the system that prevents you from quickly implementing policy changes when those things occur.
The one thing that I think gets back to what you were saying is that whatever these functions are if you are going to have data sharing at a national level, it implies, much as the last speaker said, that the function has to span the population that is going to use it. So, if it truly is national, whether it is distributed or otherwise, it means that somewhere I have to be able to look up -- truly, if we are going to share nationally, I have to look up a patient that I want to share about nationally some way. It might be that I have to hit four distributed servers or I have to do something, but it has to be national and I think that is the part that now is not invisible, but it has to be some organization that is as big as the people who want to share that supports things like authentication, certification of the users, authorization functions.
Those are the things that really have to be bigger than any individual or else you can't do it.
DR. COHN: Stan, do you have to leave this moment or --
DR. HUFF: No, I have got five more minutes.
DR. COHN: I think a lot of people were going to respond to you, I think. John Paul, were you first and then Steve and then --
MR. HOUSTON: I am glad you said what you said last because I think there are definitely some components that are more than just standards that really have to be in place that are core functions. You are not going to get the requisite public confidence in the environment unless they exist in a real meaningful way.
I think, you know, authorization, authentication, they are just not -- they are not edge functions. I mean, I think at the core there has to be -- I guess I am searching for a word -- maybe credentialing is the right word, but if nothing else, it has to be this concept that whoever participates in NHIN is credentialed in some fashion. That may be a strong word, but in all of that credentialing information may ultimately be pushed out to the edge, but there is still a substantial core responsibility that coordinates, that manages, that ensures the integrity of that type of information. People are who they purport to be.
I think it also is going to extend to having a managed such things as mundane as log information because I think part of what is going to end up coming out of the NHIN is that for people to accept it, they are going to have the ability to say who looked at my records. Who asked for my records? I can't see that being something that we can push out to the edge. It is going to have to be something that is going to ultimately be at the core in order to coordinate it. I know that sounds like a lot of work and problematic. I see Steve sort of nodding.
This stuff sort of adds up and I think that -- I got in the same discussions about CAB when I was in the security meetings for it and it -- but there are so many things that I think the only way ultimately to manage them is to make some core functions. I am not sure how you go about doing that and what organization supports it, but it is -- I don't think we can sidestep it in terms of the design of NHIN.
DR. HUFF: I think you can step through each of the things, you know, the functions and ask is this something that is the responsibility -- each system that participates has to support this and how is it then aggregated at a national level?
MR. HOUSTON: I don't think it is even aggregated. Some pieces --
DR. HUFF: Aggregated is the wrong term. How do you make it so it is usable? If you talk about data logging, I mean, that is already inherent in a lot of systems and I am going to keep the local logs and the question then is how do I make those logs available if somebody nationally wants to ask how is my data accessed. It is not a matter -- it is probably not necessary -- well, it is not necessary to assume that those logs go out into some national database.
MR. HOUSTON: I agree in that context but in another case is again how does somebody participate in NHIN? How does somebody become credentialed in order to participate?
DR. HUFF: That is something that is absolutely essential.
DR. STEINDEL: That was a good segue to some of the comments I was going to make.
You know, like Stan, I think there is going to be a lot of local functions that are already done that have been addressed as needs of the NHIN, auditing, logging, but what we probably need in those cases is to clearly enunciate that we need standards so that we can retrieve that data from stores of it, whether they exist in a regional or a local or even a national basis. So that we can combine the information. Standards for auditing, for instance, don't exist, at least not within health care.
That was just one off the top of the head example. The other is and this is -- I have a question that perhaps of John, perhaps as discussion, but, you know, we have been told that we don't do policy within this group, but we have heard a lot of times that the testifiers have called for policy in certain areas. Do we mention within ourselves that, you know, many people have said we need a policy for and I think one example is one that John just mentioned and that was credentialing. You know, there needs to be some type of national standards and policy for credentialing the people who are going to ride the NHIN. We don't have to enunciate what it is or anything, but I think we should clearly say that something like that is needed.
With regard to that, in the same vein as before, we also need some standards for how to express that credentialing as people get -- move on the NHIN. That was just some off the head examples. There are a lot more I can enumerate as we talk.
DR. COHN: Sure. And I commented and I am not sure if it was with John, but I think in the conversations there was a recognition that we would run over policy issues. I think there is a difference between identifying a policy issue, which is something that we do need to capture and record versus trying to resolve it.
DR. STEINDEL: I can assure you I don't want to resolve it.
DR. COHN: I guess I should look at John. That was my understanding of our discussions and early agreements.
MR. LOONSK: As we expressed at the forum, we are not trying to avoid the policy determinations. There are a variety of different groups that are working on them and we are trying to get policy implications out of this activity that can be fed into different groups. We are trying to get results from those groups that will be fed into subsequent steps of this activity as well.
DR. COHN: And given the time we have, we couldn't solve these policy -- we would have to be here between now and through September 15th to get them discussed adequately.
Jeff.
MR. BLAIR: My objective is to stay focused on our primary mission, which is to identify the minimal functionality that is needed, minimal but inclusive. I have some conceptual struggles and maybe in a small group we could come to some consensus, not that it is right, but just something that enables us to go forward because I am struggling. Okay?
I will give you the problem I am having. We can readily come to the idea, pretty quick consensus that the idea is the NHIN is a network of networks and that is fine. We heard that there are either RHIOs or gateways or subnetwork organizations that could all be part of those networks of networks. When we go down the idea of saying all we need to do is connect these RHIOs, subnetworks or gateways, people start to argue with the idea that the NHIN could be very, very thin.
That looks like it is simple, but then we look at accountability and we look at security and I start to feel uncomfortable that I can't just delegate authentication and authorizations and access controls to all of these other networks unless -- and I don't know the mechanism. I don't know the mechanism of saying well they are actually another part of the NHIN and, therefore, they are within our scope to say they are core or another mechanism to wind up saying, well, they are not part -- and I don't care which way we go. So, I am not arguing for a particular construct. But I need something to be able to do this with some integrity and consistency because there is a lot of the functionality that has to be consistent at the outside edges, at least for security and then I start to run into another problem.
This is why I am saying this as something that I think maybe some folks after they hear my problem, they can wind up saying, well, we could do it this way and we could come up with a construct and we can go forward. Here is the problem I start to run up with is that each of those subnetwork organizations, some are e-prescribing and some health information exchange and some are the VA and some -- they have different requirements, even for security.
Some of them have very demanding requirements for security and some are much less or even caBIG. So, do we start to impose the most stringent levels of security on all of those folks? So, I am struggling with how to deal with this. So, if there is someone that has a construct, I don't care which one it is, which enables us to deal with this --
DR. COHN: Jeff, maybe I will try to respond. I guess -- I mean, part of it is chain of trust issues, but also part of it is role-based and various other types of access controls, some of which I saw in functional requirements and some of which I haven't. I think I was getting into this consternation yesterday when we were looking at personal health records, the same sort of question about how do we handle --
MR. BLAIR: That is another good example.
DR. COHN: -- I mean people sort of touching and making sure that things stay secure and that things are not released inappropriately. That is, I guess, the lesson -- what I was hearing today.
John, you had your hand up on this one. You were trying to respond.
MR. LOONSK: One way that the issue that Jeff has brought up has been discussed is the lowest common denominator in the security area. Can you assume that your security is based on the lowest or the weakest link in the chain? That is an issue that has to be considered.
I did want to back up a little bit and note the differentiation between what Steve said, which was a system of systems and what Jeff said, which was a network of networks. I do want to point out that those are different.
MR. BLAIR: Yes. Good point.
MR. LOONSK: And again, just to get back in the framing context to the fact that I do think the name game is going to be problematic for this activity and that we have to continuously focus on not the thin versus thick, core versus not core because many of these issues still have to be resolved in other processes and contexts, but the totality of functional requirements necessary to connect up edge systems -- where an edge system could actually be a network or a system per se. It could be an EHR or it could be a network of EHRs as an example.
That is not to say that what is connecting that up is necessarily the NHIN versus another network that is doing that. What it is to say is that we have to be looking at the broad scope right now and defining the requirement or it will be very difficult to parse out and get to an end product here in the time frame we need to do it.
I don't mean to sound like a broken record. I did say this yesterday just before lunch time. I did make a point as well that when you look at the -- and when I think people see the NHIN prototypes, they are being called the NHIN prototypes but are they prototypes of this thin network that people are conceiving of? No, not really. They are going to be software prototypes of capabilities for data exchange in a more regional fashion.
You could interpret perhaps the interconnection between them as potentially being that which people are conceiving of as thin. We still are going through this prototyping stage. We are doing that on purpose because we think that there is a lot that still has to be worked out and that we are going to learn from that process and some of those results are not going to come until after this step and this work is done.
MR. HOUSTON: Is there a thought that the next step would be to take those four separate, what do you want to call them, projects and look to try to link or to do some type of evaluation, whether they could be linked effectively so that they are no longer just simply region projects but they are becoming more of a prototype for a national infrastructure.
MR. LOONSK: There have been discussions about that as a model. I think we heard some very strong voices during this testimony about RHIOs that have a lot of technical infrastructure who are very interested in doing some of those things themselves.
I think there is another extreme of RHIOs that are not at all about IT infrastructure and are about just business practices. So, there is a broad spectrum of variability that is going to exist for sometime to come. I think one model is to think about how those could connect up. Another model is relating regional exchanges that are coming from different angles and different perspectives. So, there are a lot of permutations.
MR. BLAIR: Is there anybody who could help me with my dilemma here?
DR. COHN: Maybe Harry -- I had thought that I had responded. I guess maybe I didn't resolve your concerns. Steve, do you have a --
MR. BLAIR: Say it again. Maybe I missed a resolution there that you were suggesting.
DR. COHN: Steve, did you have a --
DR. STEINDEL: Let me jump in a little bit because I don't know if this is going to resolve your dilemma, but, you know, when I was mentioning that there are going to be varying degrees of sophistication. We have heard this varying degrees of use cases for systems that were going to be using the NHIN, I mean, just in today. You know, each one of the different areas while they were -- you can characterize what they said is what you need is essential functions for the NHIN and you can characterize it as either a very thin set or all of them. But they seem to -- in each particular set, they did focus on a set of areas that really were unique to them that may not overlap all over the place.
We got this the first day with each one of the prototypes, depending on their model. We got it with the PHRs, for instance. And what I think is that what is a set of the essential functions are those functions that we can require or should require of anything that connects to the NHIN. Then we have to tease out of those 20 odd lists of functional areas and maybe sub into those areas, which are really not required by anything that will connect to the NHIN.
This kind of addresses what Jeff is talking about because some of the things that he was -- you know, when he is talking about the various degrees of sophistication of the systems, yes, VA internally might have higher security requirements than the NHIN and that might be justified. We heard that from the FHA, that the federal systems have certain more stringent security requirements that is generally used in the private sector.
Now, we may feel that those security requirements should be in the private sector. I think that is another discussion, but we also heard that what VA intends to be is essentially a gateway to the NHIN, that there will be one connection from the VA into the private sector. So, you can presume that that might run under certain security requirements. Once there is a connection in that gateway, it will be handled under the federal security requirements.
I think we might see the e-prescribing. We heard that from Kevin. We got the hint of that from Kevin that they might be willing to serve this for the same type of function with an e-prescribing arena.
So, I think, you know, addressing what Jeff is talking about as, yes, we are going to see different ways of doing this within the various systems that connect, but I think we need to talk about, okay, we do need authentification. We do need authorization. We do need credentialing. I think that has been fairly common. The NHIN should establish a set of standards to do that. That is essential.
MR. BLAIR: I would like to be able to go that path, but help me with something else. I have got some stumbling blocks to be able to go down that path. Like, for example, lowest common denominator and we wind up saying minimum security requirements. But what if you have one of your ED systems or two of your ED systems that require nonrepudiation. That has to be end to end. So, it is not like it ends at the border of that subnetwork organization. The NHIN core has to be able to take that and go all the way through to the other end. How do we deal with something like that?
MR. LOONSK: I misspoke when I said lowest common denominator. The issue I was really trying to tease out was weakest link and the concerns in regard to if you have a shared trust model and everyone has to be participating in it, how do you avoid being dependent on the weakest link in that chain? But I also think, to follow up on your other point, that it is inevitable in this kind of discussion but that we haven't drilled down far enough to really appreciate cross organizational auditing or some of the issues you are talking about, Jeff, whether they be credentialing or role-based access control or a whole variety -- nonrepudiation, a whole variety of issues where when you actually drill into them and think about them across organizations, there is infrastructure and services that need to be induced that are not currently present. It is not that we are trying to say that makes the NHIN thicker.
What we are trying to say is regardless of where they are, they have to be in place for it to function. What we are trying to do with the functional requirements is say so noted. The functional requirements need to be inclusive of those capabilities. We are not then saying that they are inherent parts of the NHIN.
They maybe edge systems that provide those services and that that is a reasonable model. We heard a little discussion -- it was certainly, I thought, very helpful to look at SureScripts, a group that is doing a lot of function that could be seen as parallel, that has a model for how they do some of that. They were definitely thicker than people were thinking about in terms of NHIN. But even if that was a model that was replicated, it could still not necessarily be considered a core NHIN, but another service that is providing those capabilities to foster it. So, that is why I keep harping on this concept of -- if the functional requirements have to identify the services, the systems, the capabilities that need to be in place regardless of where they reside, it will be in the strongest position to move forward with this activity that the way in which those are provided is really partly strategy, partly industry based in terms of working with industry to make sure that that can be a well-correlated and I do think that we shouldn't underestimate the fact that there are services. There is infrastructure.
I think we are seeing the hints of, that you get a better glimpse of when you start to look carefully at how something that is transacted from one organization to another where you have these requirements for how it would be exchanged, have to be manifest. That doesn't mean it is a thick NHIN. But it does mean that they have to be attended to in terms of these requirements and thought about in terms that they exist somewhere.
MR. REYNOLDS: I just think we are jumping ahead too fast period. We heard a lot of good stuff. I think we have -- because we have had some sidebars, we have been able to list Steve said 20 or somebody said 20 and maybe it is 10, maybe it is 8, whatever. I mean, we got some -- we had enough testimony to come up with a list of, you know, what might be, you know, that core or base functionality. I think we need to stay on our game and go through those because we have not discussed any of those yet. We listened for two days. We had a little bit of chance. But we listened for two days.
I think we need to go through there and then once we go through there, then I would feel very comfortable dealing with Jeff's question on nonrepudiation because once we had looked at what we think core functionality ought to be or the core things that we are looking at, we would know whether that is or isn't involved, can or can't be taken care of, isn't a function -- because the other thing, I think the only thing I am hearing as far as the RHIOs are concerned -- and I will play off one of John's words -- everybody wants to decide who is going to do it. So, you have got a lot of that.
You have got everybody stepping up saying I am it or my way is it. That is fine. They should be because they should be proud of what they have done, but we can't fall into that and we can't start lining them up as whether they are, you know, core or edge or anything else. We talk about functionality and then there may be some people that play the whole gamut. Good. As long as they meet the standards, as long as they meet what we said we were going to do, as long as they meet the requirements, you know, fine.
But if we get caught up in that, then I think we will lose sight of the -- we are supposed to be talking about functionality and any time you design or think about anything, you look at the 80 first and then you put the other 20 against it. We got to be careful because a lot of the presentations were at the 20 or were at the 5. We wanted to hear a cross section. That is not good or bad. That is just what we asked them to do.
I feel good. I think we got a lot of good information in two days. I think we got some structure last four or five -- probably there were six presentations that really took our questions ultimately seriously and took the whole function ultimately seriously and really laid out some ideas. Now, I am not agreeing or disagreeing with the ideas, but they gave us a nice -- they gave us at least a template to discuss it from.
So, that is where I think we are. So, I am pretty happy with where we are and I think we are going to have a short list of how to go about it and I didn't say we were going to have a short answer. But at least I think we have got a structure and I think if we try to jump any further than that right now, everyone around this room could either blow it up or make it simple. Make it thin or make it fat.
I think we are in good shape. I think we are in a good spot and I think we just need to go about it.
DR. COHN: Maybe do a little more analysis of all the things we heard.
I think Mary Jo and Steve and then Judy.
MS. DEERING: What I am offering may boil down to not much more than editorial later when we come to present it, but a lot of this discussion has been requirements in terms of things that do boil down to some aspect of security and I would like to just offer that what I also took away is another perspective of minimal requirement, which is for the connectivity itself again. Not whether you need to do -- Steve is shaking his head.
DR. STEINDEL: I agree with you, Mary Jo.
MS. DEERING: And it is a more affirmative approach, shall we say. I mean, this first approach has been one of constraint and concern and appropriately so, but the other is affirmative and supportive of a lot of those things that are at different levels of connectivity and/or that are faced with multiple gateways of connectivity. I took very seriously Kevin's slide, you know, this one, where he contrasted the national versus the RHIOs. Then if you add a lot of perhaps individual entities that have to be part of the NHIN and who don't necessarily see themselves as part of any of those subnetwork organizations, then I think we also have to keep that image in mind as we move forward.
DR. STEINDEL: Well, I thought I was just going to say I am not going to follow Harry because he basically expressed most of the thoughts that I was going to say, but since Mary Jo introduced -- I want to say the only reason I mentioned like security and auditing and -- it just happened to pop to my mind. I think Harry, you know, gave an estimation of probably the scope of what we were looking at and it is probably somewhere on the order of 20 plus or minus. I don't know what high level or how high a level, but things like connectivity would fall into them when we start discussing outside of the two days of intense hearing and brain frying.
DR. WARREN: I was going to say I almost would like to say ditto except I would like to add one more dimension to it of when you asked us for comments, I was sifting through my head of what the comments were, but I could only think of the high things that we heard this afternoon. It was hard for me to go back and remember what we heard this morning or yesterday. I am at the point that I am sure everybody else is. The brain is not working as well and I almost need a chance to sit down and analyze what were in each of those presentations and to do kind of a grid or something so that I can figure out what was there and what wasn't there.
That is all I will say. I don't think I can make any kind of informed discussion right now because probably tomorrow I would say, oh, God, did I really say something like that and want to deny it.
DR. COHN: Well, Judy, you actually bring up a good point about whether or not we -- we obviously have a consultant who can help us and rather than spending a lot of time worrying about it, this is the occasion where we take the pieces and massage them and then begin to look at them, begin to send them out for comment and begin to sort of begin to produce things.
John Paul, you had a comment. Marjorie.
MR. HOUSTON: I have more of a question. Can you as articulately as is possible restate our charge, just to make sure I understand exactly what we are -- listening to all these presentations almost seems like at times it -- I lose sight of what we are trying to do.
DR. COHN: I think it is relatively -- actually nothing is straightforward. Never is anything straightforward, but what I will read to you is basically what I read this morning, as well as yesterday and it is basically taken from agreements that we had with the Office of the National Coordinator about what it is we were supposed to do.
We were asked to review and synthesize the results of the June meeting and by the end of September to find a minimal but inclusive set of functional requirements for the initial definition of the NHIN and its possible architectural forms. What that other piece tends to mean is, well if an architecture is completely different and it requires different pieces, that we need to do that.
DR. WARREN: Would you just read that one more time because I thought you said look at architecture and I thought we weren't doing that.
DR. COHN: No, no. Basically, I was describing -- we basically just need to be aware that requirements may differ by architecture. We are not making decisions on architecture. We are not making decisions on policy but we are obviously observing all of that. You can't talk about functional requirements completely without -- in a complete vacuum.
MR. HOUSTON: When we say the NHIN, just to definitionally make sure I am -- define NHIN in the context of that statement just so I make sure I understand where our boundary is.
MR. LOONSK: The terminology is very problematic here and I have seen this before, but whenever you say "network," people have a concreteness to that that is difficult to get past and the "it" in this regard is the initiative. It is not the thing that some people have been trying to define for us, thin versus thick. What are the requirements we have to work on to meet the goal, the vision of what this is. Some of those requirements will exist for edge systems. And some of those requirements may exist for connected networks. We are not looking to delineate those right now. We are looking to look at the broad initiative and make sure we have got the inclusive requirements that can help move it forward.
DR. COHN: I was trying to think about whether to have Margaret put up that slide that we had talked about, which I think we know needs to be changed. So, I wasn't really having her do that at this point. But if you think about it, it is sort of, to use the term, sort of edge to edge and it is really about more than just edge to edge. It includes the edge systems and it needs to basically be able to do things from one side to the other in an appropriate fashion.
MR. LOONSK: And clearly not requirements for an edge system to carry out activities internal to its -- for example, if you are talking EHR, we are not talking about functional requirements of providing EHR services to the clinician using them, except as they relate to connectivity.
DR. COHN: Now, Marjorie, you have been very patient.
MS. GREENBERG: Actually, this isn't what I was going to comment on but just the bottom line I kind of came down with as to what this is about is I thought it was best expressed really by Robert Cothren, one of the four -- Northrup Grumman. But --
PARTICIPANT: He is known as Rim.
DR. COHN: He was supportive of the rim, too.
MS. GREENBERG: I thought I heard John kind of concurring with this that it isn't so much what is NHIN and what is edge, but what are the minimal but -- and if I am wrong, you can tell me. That is fine, but minimal but inclusive requirements for essentially nationwide interoperability for being able to -- as he said, the requirements of interoperability may be addressed by core or edge systems. But it is basically those minimal requirements for that interoperability.
MR. LOONSK: I think the complexity with that could be could be that some interoperability is related to intra --
MS. GREENBERG: I realize that. That is why I said nationwide operability. But in any event, be that as it may, I mean, I think it sounds to me like we are somewhat moving away from what should be here and what should be there. It really is what does it take to connect securely, but I really agree with what Judy said. I guess I am struggling less than Jeff. Partly I am not a committee member and I don't have to vote, but partly because of the woman, though, who is sitting next to me because I figure, you know, it is like the kid who doesn't worry about anything because mother will worry about it.
MR. BLAIR: Actually, I think some of my concerns at this point have been resolved by clarifications -- so I am satisfied.
MS. GREENBERG: I figured we engaged Margaret to now go through all of this and I don't envy her for it, but I know she is woman to the task because it really does require that now. I want to really congratulate those of you who put this hearing together. I think it was really a good job. I thought it was not only very, very interesting but I think we heard from as diverse a group as one could hope to in the few weeks that you had to put it together. Mary Jo and everybody else around the table and not in the room, but who participated, I am very gratified by it, I must say.
It sounded like -- I can compare these two days to when I went to the regional hearings on privacy and I said, oh, my -- people were all over the map and people, one after the other were getting up and saying the absolute opposite of the person before. Well, it is that kind of an issue but we still came out with, I thought, a really credible letter.
This wasn't like that. I think this wasn't like that at all. Even the people who seemed to be saying different weren't saying things that different it seems, but I still have the feeling that the devil is in the details and that is why I think it really does require someone, you know, to look through what people gave us, get down, as you said, below the top level into some of those more detailed levels and that can't be -- you know, that has to be done probably by one person or a team of people who just has all the documents and heard it all and understands it and takes it all into that.
The one thing that I am struggling with a bit because of that, because I have this sort of little fear that the devil is really in the details is there was this kind of self-esteem of not everybody -- this was the only place where I saw really maybe difference of some people kind of feeling like you really should be focusing on is that EHR use case and less on the biosurveillance use case or the PHR use case for the -- there were a few people who made that comment. Shake your head all you want, Steve, but some people did say it.
But, obviously, we can't do that because there are three use cases and this will have to meet use cases well beyond the three that are being discussed. So, what isn't clear and I think someone asked the question and I don't know if really drilling down into all the documents will help clarify this. Somebody yesterday asked the question what functionalities are unique to the uses other than the care use, the electronic health records use. I think the minimal but inclusive can't just include the health care use obviously. It has got to include these other uses, but that is the one question I really have is whether there are some functionalities that when you are trying to think minimal really wouldn't be so necessary for the care use case and then if so, is there some way -- but you still need them. So, is there some way to make them not overly burdensome so we don't weigh down the whole system.
That is a question that I have and I think it requires really looking at the details.
DR. COHN: We would actually love to hear the answer from you after you have analyzed the document.
MS. GREENBERG: I am not going to do that.
DR. COHN: I don't think that we actually should do the analysis on it only because I don't even know how you would do it. We have functional requirements. These functional requirements are loosely tied to use cases, but not tightly. So, we would have to go through and, you know, our own judgment determine what functional requirement related to what use case, which would be sort of secondary -- I mean, we would have to hold a whole hearing on that.
MS. GREENBERG: Well, maybe it came out sounding like -- different than it was. I do think there are some that are related more to one use case than to another, certain requirements.
DR. COHN: I guess I should ask --
MS. GREENBERG: Maybe it is not true.
MR. LOONSK: I can direct you back to some of the initial discussions we had because there actually -- the requirements that had been submitted from the consortia actually were parsed by use case. One of the attributes was what use case they were associated with versus what -- but in the spreadsheet, it is there.
The other access that they are all delineated along is entities or -- so, we had functions and the functions are -- you teased out those in terms of looking at them, but we also had systems or services, entities as they were called and that tended to rely more concretely to software and then also use case. So, same requirements but with each of those classifications, where you can sort them and resort them according to those delineations.
That being said, I do think that our -- and we have to anticipate that the DHIM is going to grow organically but that our initial -- much of our initial detailing comes from the breadth of these use cases and all three of them are very much on tap for --
MS. GREENBERG: I know they are. It just seems to me that some use cases declare more of one thing than another. I don't know the extent to which we have to understand that or worry about it. Maybe not.
MS. AMATAYAKUL: Well, I can only suggest that I have actually done a number of sorts and sorts within sorts, but one of the sorts I have not doe is by use case because I actually didn't feel like -- I thought that would biasing. So, I did not sort by use, not that I couldn't or won't in the future, but I just -- it just didn't seem to make sense as my initial pass through.
MR. LOONSK: The other thing I can add is that as different groups have looked at them and for example from a standard perspective, the HITSP technical committees, that when you drill down further into them and someone, I think, referenced the action, there is actually a tiering of the hierarchies of the use cases. When you get down to the detailed level of the actions, that they tend to look -- start to look an awful lot alike and what people were doing was converging, not diverging in terms of the fact that many of the requirements are, indeed, the same when you start to get down to that level. I think that that is something that should be encouraged.
MS. GREENBERG: I was just reacting to some people who were indicating that there might be some functionality required by some of the non-care delivery ones that you shouldn't force on people. You know, I don't think we can do that.
DR. STEINDEL: We heard a very good example of that, John, this morning when Floyd said well there was one what they called IPs in HITSP. That was biosurveillance and he said it was changed this morning. It is now joint. So, as we take further and further looks at these, we find they stretch across multiple use cases.
MR. LOONSK: There were comments by the Leesburg testimony that suggested that biosurveillance shared a lot with research needs.
MR. BLAIR: I think what we are trying to do is trying to structure how we proceed with the analysis and
I --
PARTICIPANT: I don't think so.
MR. BLAIR: You don't think so?
DR. STEINDEL: I don't think we have gotten to that point yet.
MR. BLAIR: Okay.
DR. COHN: Did you have a comment to make specifically or --
MR. BLAIR: The only comment is, you know, Harry, I think, and John wound up addressing some of the dilemma that I was facing. I think sufficient enough for me to resolve it. Now, the next thing I was thinking of is that there is a lot that has been done and I know that Margaret has been doing a lot of analysis as we have gone through this and I know that we heard a lot of testimony. So, I would really like to ask if Margaret has some suggestions or ideas of how we might organize to take our next steps.
DR. COHN: Before we get into that, let me let Linda comment.
MS. FISCHETTI: I just wanted to check with the group to see if this would be useful as well. When we heard the testimony or the report out from the June 28th/29th meeting, when we heard the testimony today there were a number of people who volunteered priorities. I need this first. Is that something that we should pick up and glean within the scope of this work or are we looking at really just a spectrum of functions with no priority tag to them?
DR. COHN: Maybe this is a time to let Margaret give us some of her thoughts.
MS. AMATAYAKUL: I guess actually I would like to ask for the slides or whatever material the June forum produced because I don't have that. I have my personal notes.
MR. LOONSK: They can be shared. There were several products, breakout presentations can be shared. They are on the web site now. But also we have more detailed notes from the sessions that are also shareable.
MS. DEERING: All we got was the combined -- originally, it was the combined slides we put together from the report out. So, that I thought I did give to you.
MR. LOONSK: I do also at the risk of straining the absorption of information further want to commend to you the next American Health Information Community meeting, where there is going to be an update. The community has asked for on the NHIN activity, not the functional requirements per se, but there is going to be an activity around the session where we will have the four consortia and we will represent some of the discussion at the forum. I think that some of the issues and some of the questions that we are going to basically present questions to them and have them answer them in that context with some of the questions and answers there may be helpful to you in your thought process as well.
We will ask questions, for example, about addressing some of the issues that have come up here in this discussion. So, I think it will be relevant and I hope to have a good discussion that will also support you in your work.
It will be recorded and on the web. It is live on the web, but they have also been historically recorded.
DR. COHN: So that will be yet another piece of -- just in case you don't have enough input.
MS. GREENBERG: What about the priorities because I remember way back --
MR. LOONSK: I think to a large extent we have had our priority expressed for us in the articulation of the use cases and that that is the representation of what the community has said is to be prioritized. We have also recognized the separate bin of general NHIN infrastructure. We asked for the consortia to think about that in terms of requirements. We have obviously heard a lot of testimony from people who have interest in additional functionality.
I think that we need to in this first set make an initial effort at seeing that systems functionalities are in place to support those activities, but recognize that the much more detailed functional requirements that would be associated with additional use cases would by necessity have to come in subsequent time periods.
I think that there are a number of activities that are going on that are related to those specific use cases and endeavor to remove barriers. We heard about, for example, CLIA issues that relate to some lab result reporting. There are efforts going on to look at those issues and to try to work through them. So, that is just an example of the multitude of things that are being arrayed to address these specific use cases because they have been identified as priorities and we need to keep that focus for this activity as well.
DR. COHN: I tend to agree. I think there are many who have sort of commented that this is a time for more doing some analysis. I mean, the general feeling that at the high level, I think that our -- I am at the first level concerned about the high level framing that we are creating and my sense is that what we have heard is a lot of confirmation. It is not perfect and we will be modifying it further, but I think that high level framing is probably the right high level framing.
I think once again we will be further refining it and all this stuff but I think that is an important piece. Then from there, I think we can analyze further requirements in a number of different ways, knowing that a lot of them fall into hierarchies and things like this. So, I think we really are not talking about 1,100 different requirements or even 900 or 84, but really at the critical level that we are really concerned about there are a much smaller number than that.
Now, I certainly think it would be probably interesting and certainly if it is available, it might be interesting to at least compare, I mean, their requirements for the use cases just to sort of see what they look like, just because I think -- when I made my comments, it didn't sound like it was going to be an easy thing to get to, but it is one of 20 different ways of sorting things. So, I think we can at least look to that to see if it tells us anything.
Certainly, part of our product is going to, of course, include the 12 inches of material at this point that we are accumulating. So, we won't have to worry that any of it is going to be lost.
MS. GREENBERG: If it does show, which it sounds like preliminary analysis indicates it, that if these two or one of use cases or two of them don't dramatically swamp a third one, that is an important finding also that if the functionality is very similar across the use cases because I think -- I really think that what we heard from at least from testifiers, if you are going to get any support from the public, it is only going to be -- it is really for the care system one. Perhaps I am sensitive to the fact but those of us in public health have been hearing for years that we are the ones who burden the system with all of our requirements and then when they actually looked at it, it really wasn't the case, whether it be the discharge data set or whatever. So, I think it is an important finding and it is an appropriate one for this committee if you found that. But you have got to be honest about it. If you find alternatively that one or the other use case does create a lot of additional functional requirements, then I think it is important to get that out. That is all I was saying.
DR. COHN: Okay. So, are you disagreeing with what I was suggesting there or were you agreeing? You agreed. Good.
MS. GREENBERG: I think that is important to --
DR. COHN: Okay. So, we said we were going to do that.
MS. FISCHETTI: Just as an observation, I believe that our output will look most like the FHA testimony because if you notice the FHA testimony had to take multiple stakeholders. So, I was waiting for the group to fall out of their chairs when they said 900 requirements because the previous testimony had been parsing it for edge and core; whereas, this was that global -- this is what you need to get the job done with no -- that is just an observation.
DR. STEINDEL: Actually, Linda, I felt we heard that from I would say 80 plus percent of the testifiers. It is just that the FHA stated it the most bluntly. We heard continually, I think, from all of them that when they started going through the list of whatever number of -- how many are there, John? I forget.
PARTICIPANT: 20.
DR. STEINDEL: Yes, the 20 odd -- you know, every time we heard that, you know, everyone of the testifiers said, well, we need this one. We need this one. We need this one. FHA was just blunt about it. We needed them all. I didn't really see much significance there.
MS. AMATAYAKUL: I was going to say that we do have a call soon, August 8, I think it is, 7th, whatever. It would be helpful for me to have just a brief discussion as to kind of what our agenda would be for that because I am sort of looking at trying to do some checks and balances kinds of things where I am going to take what I heard in these two days and try to come up separate from that list of 900 plus what I heard.
Then go back to the list of 900 and try to reconcile that is there anything that if you get it bubbled up, that there is grossly missing. I think I sort of see the use case in the same manner as really more a check or balance that once you have got what you think is an initial draft set of functions, then you go back and you look at it in multiple ways and say did we leave something out or is there some imbalance there.
So, I don't see doing some of these cuts until a little bit later, after we get -- I think, as you suggested something more of a framework or some framing of what we are looking at. But I do think it would be helpful to kind of think about do we want that first cut of what we heard today, yesterday and today plus some modification of our framework, picture thing, for the 7th. It would be helpful for me to know if that is what we are going to try to do on that day.
MR. BLAIR: -- looking for some guidance from us on that. I think she is asking a question.
DR. COHN: Well, I was answering in the affirmative, Jeff. What are your thoughts?
MR. BLAIR: Well, when you said you were answering in the affirmative, the affirmative means what in terms of guidance for Margaret?
DR. COHN: I think she was asking a yes or no question and I was answering yes. At least that is what I thought I was doing.
MR. BLAIR: Ask the question again because I didn't know it was a yes or no.
DR. COHN: I think it was a yes or no, wasn't it?
MS. AMATAYAKUL: I think I was -- I was asking for guidance but I was proposing that what I would -- I think might be a first step for that first call or the agenda be to look at the framework picture and to look at what we cull out from yesterday and today testimony as sort of high level functional requirements. It is a minimum but it is inclusive and that then we proceed to do checks and balances after that because if we -- even if we took only the 300 plus core or if we took only the little bit less than 300 plus core shall, in a two hour phone call, we would get, you know, 30 done. We can't do that, I don't think.
DR. COHN: Those are things we will be doing looking at off line and confirming.
MS. AMATAYAKUL: Exactly.
MR. BLAIR: That is what I was thinking of when I was thinking of how do we -- I took a look at one point on a number of those with Margaret and there were a lot of them where those requirements needed clarification or definition or they were ambiguous. Now, I -- because we have worked with Margaret a number of times before -- have a lot of trust in her to begin to aggregate with fidelity and integrity a lot of these to eliminate the redundancies and boil them down to a high level list. But I think that that is what is going to be needed before we meet this next time because I don't think we have a way of dealing with 300.
MS. GREENBERG: So, he said yes. too, Margaret.
DR. COHN: I think you agreed, Jeff.
Now, the truth is that I don't want us to -- we are running down now and we have got about another five to ten minutes and we are going to finish. So, this is not the time for us to be as a large committee working on a project plan. Project plans occur off line. I think we are providing the input. We will be obviously working with Margaret off line a fair amount to help refine things and have ongoing calls. So, I don't want to spend our sort of remaining couple of minutes in terms of deep discussions of exactly what it is she is going to be doing next.
Now, as I say that, Linda, do you have a --
MS. FISCHETTI: No.
DR. COHN: Okay. So, I am okay on that.
Now, what I wanted to do at this point, since we are getting closer to 5:00 is really talk about the next steps just sort of generally. Now, as I said I think we have said this before, but (a) we have -- the subcommittee has a number of calls scheduled to sort of go over -- they will be working calls. They will be calls of the workgroup to sort of look at the work products.
I think we have three of them. They are August 7th, the 16th and 31st. With really the big one being on the 31st when we will be asking for public comment.
Margaret, I guess at this point we had talked about maybe sending out some drafts of spreadsheets. I don't sense that we are sending -- I mean, we are not going to be sending those out immediately. I think those have to be probably sometime in early to mid August. So, this will be an opportunity for people who presented, who have opinions or otherwise, who want to review things. The public could at least get an early view of, I think, of our analysis as we go forward, once again, in preparation for that 31st call.
Now I do want to remind everybody that we are open for additional input from the public in terms of written comment through July 31st, close of business. Those on the Internet, those here, those who have testified. We certainly welcome additional written comment based on anything that you have heard, other comments that have been made through this testimony that may cause you to think about things differently or want to make additional comments.
I want to make sure everybody realizes that with the close of these hearings, the door is not shut and this once intended to be a very open process, which will obviously culminate with I think sort of final recommendations in mid-September for the NCVHS.
Marjorie.
MS. GREENBERG: Just within the process part of it. Obviously, the end goal is to get approval of the full committee in September. We have at least a third, maybe more than a third of the full committee involved already directly. This is complicated technical stuff in many ways and I think that on the one hand, many other members of the committee may kind of defer -- I mean, will defer to the ad hoc workgroup because they are not going to have the ability to go through all this in the same level of detail.
Nonetheless, they are also -- need to be factored in probably, you know, certainly as soon as the broader community is and maybe sooner than that. When you have something to share with the presenters, the public, et cetera, obviously, I think that there needs to be a transmittal to the other committee members so that they are brought along --
DR. COHN: What are you suggesting as we move to drafts, we should make them available. I think we have also talked about in terms of all this stuff that we may very well probably in early September, I would imagine, after that open call have a call with the committee members to sort of update them on this. We could also invite them to the August 31st call also.
MS. GREENBERG: That is what I was thinking, whether it wouldn't be a good idea to send a note to the other members saying, you know, we have had these two days. We went to the forum. We have had these two days of hearings. You know, we are moving along. This is our plan and we are having this call on August 31st, which would be a very good opportunity for you to --
DR. COHN: That is a very good idea. Okay.
DR. WARREN: I have a process question to build on this. I think we need more than just committee notes. If people's calendars are like mine, it would be very nice to know in four weeks we have a conference call.
MS. GREENBERG: No, I think we will try to do that like on Monday. It doesn't have to be long, but I just think that --
MS. DEERING: My housekeeping process question has to do with quantities of people to be involved on the calls and on the especially the four hour call. I just wanted to put on the table that whereas I had originally planned to host all the calls and the center web session on our own technology, there may be a need for RSVPs, just for quantity.
Even if I don't handle it, even if NCVHS decides that you have got some other approach, I think the direction that our conversation is going suggests that we will get to a point where we need RSVPs, simply because the technology requires it. You know, you have to reserve x number of lines. At least you have to second guess how many you are going to get. So, I just wanted to leave that on the table as possibly something to build into the notes to the committee, et cetera, you know.
MS. GREENBERG: Okay. We will coordinate with Katherine Jones and, you know, what we need to do.
So, you are thinking that it is going to be something -- what is our kind of tentative date for something that would then be available for people to look at.
DR. COHN: Is this something that we need to determine right this moment?
MS. GREENBERG: Well, no. I think we have to have a general idea.
DR. STEINDEL: What I heard from Mary Jo just now is especially with respect to the 31st conference call, she would like kind of a list of what is going on. I would think we could post something in general now, you know, just generally stating that we will have an open conference call on August 31st. Please respond to Katherine Jones or whoever, you know, if you plan to attend. Mary Jo just needs to know how many --
DR. COHN: But I think you were asking something different.
DR. STEINDEL: think she is asking something different.
MS. GREENBERG: Is it reasonable to say that the discussion document will be posted a week before the call or -- is that our intention?
DR. COHN: Yes. I guess I was confused only because I think we have been talking about a draft document out as well as all this stuff. So, I didn't exactly know how the timing of that was going to be. But certainly whatever it is, we are going to discuss on the 31st would need to be out by certainly a week before. But I don't know that we are necessarily -- I am not sure exactly whether we are posting it as a draft document. We don't normally post on our web site draft documents.
MS. GREENBERG: Yes, we do if it is --
DR. STEINDEL: And also, Simon, in this particular case we might have people that have e-mail addresses to send the document to.
DR. COHN: That is what I am saying. Normally we would send them the e-mail document or whatever because we would know who they are but we can certainly also put it on the web site and just note it as a draft document.
DR. STEINDEL: We did that with the e-prescribing letters, too.
DR. COHN: Once again, I don't know that we need to discuss this at length during an open session. We have a number of different pieces going on at the same time.
Obviously, much work to be during the summer. We know we have a number of calls in place. We will be having hopefully a draft document for everyone to review and provide us comment on before the 31st and then hopefully there will be a second revision by a week before the 31st, based on anybody's comments at that point.
Once again, just sort of moving forward.
I want to thank everybody. We are running a couple of minutes late. I think it has been a very useful set of hearings and I am actually very pleased with where we are at this point, which is a lot of information I think to evaluate. I think some views that -- our initial views are not so divergent from I think what we were hearing from the private sector and from our testifiers.
I want to thank everybody --
MR. BLAIR: Especially Mary Jo for the way she pulled together this very successful agenda.
DR. COHN: And to my vice-chairs, Jeff Blair and Harry Reynolds without which we would obviously not have had these hearings for these two days.
So, thank you both very much.
Okay. With that the meeting is adjourned.
[Whereupon, at 5:05 p.m., the meeting was concluded.]