[This Transcript is Unedited]
Humphrey Building
200 Independence Ave, SW
Washington, DC
Agenda Item: Call to Order and Introductions
DR. COHN: Good morning. I want to call the meeting to order. This is the first of two days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The Committee, I think as you all know, is the main public advisory committee to the US Department of Health and Human Services on Health and National Health Information Policy.
I am Simon Cohn, Chairman of the Subcommittee. I want to welcome fellow subcommittee members, HH staff, and others in person. I also want to let those here and in the audience know that as an unusual turn of events, we are actually not on the Internet today or at least won't be for this morning. I don't know if that changes the fact that you need to speak clearly and into microphone, but we're obviously not going to be asking you to do that for the sake of the Internet this morning.
With that, we would like to start with some introductions around the table. Now, I am going to ask the subcommittee members to indicate during their introductions, their affiliations which may in any way affect their judgment or otherwise in relationship to the users before us today, which as you all know have to deal with making steps for patient medical record information standards. And indicate your affiliations, other interests, and otherwise.
So with that, I guess I will start off by introducing myself. I am Simon Cohn. I am the Chair of the subcommittee and member of the national committee. I'm the National Director for Health Information Policy for Kaiser-Permanente. In terms of my affiliations, I'm a member of the ANSI-HISB, a member of the CPT4 Editorial Panel. I think that's it for the moment.
Jeff?
MR. BLAIR: Hi. I'm Jeff Blair. I'm Vice Chair of the Subcommittee on Standards and Security. I'm employed by the Medical Records Institute and I am a member of ANSI Healthcare Informatics Standards Board. I'm a member of HL7. I'm a member of ASTM and I think that that's it.
DR. MC DONALD: I'm Clem McDonald from Indiana University and Reagen-Streef Institute (clearing throat),and I am chairman of LOINC, the coding committee for measurements and laboratory tests. I'm a subcommittee chair of HL7. I'm a member of ASTM. I'm a reviewer of DICOM documents. There are probably others in there you guys remind me of if I forgot.
DR. FITZMAURICE: I'm Michael Fitzmaurice, Senior Science Advisor for Information Technology with the Agency for Healthcare Research and Quality. My agency supports the meetings of the ANSI Health Informatics Standards Board to coordinate the National Standard Developing Organizations.
MR. SIRAKOWSKY: I'm Art Sirakowsky. I'm sitting in for Mel Groverman today from the Food and Drug Administration. I'm a member of the International Standard Organization. I'm also the Co-chair of one of the subcommittees for the American Advancement and Medical Implementation. Again, I'm with the Food and Drug Administration.
MR. DICKINSON: Good morning. I'm Gary Dickinson with Per-Se Technologies. I'm a member of HL7, ASTM, NCHISB and the list goes on. Thank you.
DR. HUFF: I'm Stan HUff. I'm with Intermountain Healthcare in Salt Lake City. I'm also a professor at the University of Utah School of Medicine, current Chair of the Board of HL7, Co-chair of the LOINC Committee, Advisor to the SNOMED Editorial Board, a member of ASTM.
MS. GILBERTSON: Lynn Gilbertson from the National Council for Prescription Drug Programs, otherwise known as NCPDP and I am a member of WEDE(?) and also the DSMO secretary for this year.
DR. BEHLEN: I'm Fred Behlen. I'm assistant professor of Radiology at University of Chicago. I represent the University of Chicago Hospitals in HL7, member of the American College of Radiology Committee on DICOM Standards and represent the American College in DICOM and I'm Co-chair of the Joint Working Group between DICOM and HL7, which is called DICOM Working Group 20. And on the HL7 side it's called HL7 Imaging Integration.
MS. KRATZ: Good morning. I'm Mary Kratz and I'm the Health Science Lead for Internet2 Project. The list of suspects, let's see, I'm the past Chair of the Object Management Group's Healthcare Domain Taskforce currently serving as their liaison to ISO-TC215,a member of the US Tag for ISO-TC215, member of ASTM, HL7 where I served as the past Chair of the Securities Special Interest Group there, IEEEX12. The list goes on with the usual suspects. Thank you.
MR. STEINDEL: I'm Steve Steindel with the Centers for Disease Control and Prevention. I'm CDC Liaison to the SNOMED Editorial Board and to ANSI HIS. I'm also staff to the NCVHS Workgroups on the National Health Information Infrastructure and Quality.
DR. BALL: I'm Judy Ball from the Substance Abuse and Mental Health Services Administration and staff to the subcommittee.
DR. YASNOFF: Bill Yasnoff from the Centers for Disease Control and Prevention. I'm CDC Liaison to the Association of State and Territorial Health Officials and also to the National Association of County and City Health Officials.
MS. BEEBEE: I'm Susie Beebee with the National Center for Health Statistics. I'm staff to the subcommittee and a member of WEDE, X12, HL7.
MS. GREENBERG: I'm Marjorie Greenberg from the National Center for Health Statistics, CDC, executive secretary to the Committee.
MS. ADLER: Jackie Adler, staff to the Committee, NCVHS.
MS. OLWA: Vivian Olwa from the National Library of Medicine.
MS. WILFORD: Hi. I'm Heather Wilford from the College of American Pathologists.
MR. RUBIN: Ken Rubin from EDS supporting the Veterans' Health Administration and a participant in HL7 and the Object Management Group.
MS. WILLIAMSON: Michelle Williamson, NCHVS.
MS. JACKSON: Debbie Jackson, National Center on Health Statistics staff.
MR. ESMONGA: Don Esmonga, American Health Information Management Association.
MR. MAURY: My name is Henry Maury from International Care, caregiver for Mr. Jeff.
MR. SELIGER: I'm Rob Seliger. I'm President and CEO of Sentillion a vendor of information technology for the healthcare industry.
MR. SCANLON: I'm Jim Scanlon from HHS-ASPI, Executive Staff Director for the Committee.
DR. COHN: I should comment before we get moving to the hearings that there's whispering here, but we're trying to get a speakerphone set up. Kepa Zubeldia, one of the members, injured his back over the weekend and as a result is going to be conference calling in with us. We had anticipated that he would be able to listen in via the Internet. Buy as you all know, the Internet is down this morning. So you may have to interrupt the hearing testimony at some point, but we will do that between speakers to set up the phone and it will be, hopefully, relatively unobtrusive.
I think we commented, and I will give this over to Jeff in just a second, the focus of these hearings is really on patient medical record information standards and next steps based on follow up of our previous report last year. In all of this, I want to thank Jeff Blair, Mike Fitzmaurice, Susie Burke-Beebee for their help in terms of putting this hearing together. Jeff is our Vice-chair and has been really the leader in the clinical and patient medical record information standards activity.
With that actually, Jeff, I'm going to turn it over to you --- and I'll assist as you need. Once again, thank you for your help.
MR. BLAIR: Thank you, Simon.
Let me give you all a little bit of background here so that you'll be able to put these hearings in context. Last June and July when we finished our report to the secretary on Uniform Standards for Patient Medical Record Information as called for within the Administrative Simplification Provisions of HIPAA.
We included in that ten recommendations and they really reflected the fact that we needed to have an overall framework for proceeding with PMRI standards. Among the things that was in those recommendations was a set of guiding principles.
These guiding principles for selecting PMRI standards are similar to the ones that the NCVHS used back 3,000 years ago when we were selecting the financial administrative transactions. It seems that long and we modified them to make them more appropriate for the selection of patient medical record information standards.
The guiding principles when we started to look at them a few months ago to help us with the selection of PMRI standards we had some discussions. Among the discussions that we had was that it would be wise for us, and Clem is the one that kind of brought this up, McDonald, if we look for the low-hanging fruit so to speak and, in particular, the message format standards would be the first phase of the PMRI standards that we might recommend.
We indicated in our report a year ago that we'd give the recommendations for the first phase 18 months after our initial report. So that's about a year away from now and as we've proceeded, we wound up stepping through trying to look at those guiding principles. And we found that we needed to revise them a little bit. And this is the day when we've taken our first few steps in the NCVHS in the subcommittee to try to pull together a set of criteria for selecting these standards, a list of those areas that might be candidates for message format standards and a draft questionnaire that might be appropriate to give to the SDOs in maybe the May time frame if you all wind up feeling that the questionnaire and our criteria are on-target.
So, you could kind of relax. I'm addressing our testifiers now. You could sit back and you could relax because your role today is to critique that framework, to critique our criteria, to critique the appropriateness of the questionnaire, to critique the areas that we might focus on. And we've done our best. During this next day and a half, we've tried to invite what you might consider to be the mainstream, the leaders in message format standard developers.
We've also tried to wind up getting as much diversity as possible so we could wind up making sure we benefit from different perspectives as well and it's going to be kind of a collaborative dialogue as we go through this. Although it's kind of a formal room with microphones, I encourage to you to just relax and give us the benefit of your knowledge and wisdom.
Now, I think we have either five or six testifiers here and since I can't see anyway and since in many cases you could almost select it yourself, let me ask this. If you introduce yourself from left to right, then maybe that could be, just your names, and then we'll follow that pattern as we go through.
MR. DICKINSON: Gary Dickinson, Per-Se Technologies.
DR. HUFF: Stan Huff, Intermountain Healthcare.
MS. GILBERTSON: Lynn Gilbertson, NCPDP.
DR. BEHLEN: Fred Behlen, DICOM.
MS. KRATZ: Mary Kratz, Internet2.
MR. STEINDEL: Steve Steindel, CDC.
MR. BLAIR: Okay. For the most part, this is intended to be the 'panel representing SDOs'. Not everybody was able to make it for the other panel. So we've made some modifications on that. Generally, that's the case.
So, Gary, could we start with you and proceed from left to right.
You all have about 15 minutes to present and then after that, we'll have additional questions and comments and we'll continue our dialogue after that.
You can turn the speakerphone off now. So give us just a second to get this calibrated.
FEMALE SPEAKER: Kepa, can you hear me?
DR. ZUBELDIA: Yes, I can.
MR. BLAIR: Why don't you hit maximum volume.
(Conversation setting up speakerphone.)
DR. ZUBELDIA: I can hear you okay.
Agenda Item: Testimony of Standards Developing Organizations About Elements of the Proposed Process
MR. DICKINSON: Good morning again. My name is Gary Dickinson with Per-Se Technologies.
After that great introduction, Jeff, I feel like I'm testifying on the wrong topic, but that was by request so.
In any case, I do the issues of the standards that you're addressing today are near and dear to my heart as you know and rather than writing two sets of testimony, I'm really just going to focus on the items that I was requested to cover today. So I'm going to be a little bit off-topic and hopefully that will not dissatisfy anybody too greatly.
My major concern, and I've been out visiting our customer sites here looking at HIPAA and HIPAA implementation requirements, looking particularly at privacy and security since transactions and code sets have been found to be relatively straightforward from our perspective although there are obviously some issues there.
Privacy and security have the unique aspect that they basically encompass the entire operation of a provider organization, including all places where they may capture, retain, convey, individually identifiable health information. And so our concern, looking at this, is that we have, obviously the clock is ticking on privacy and our customers as well as ourselves are having to step up the plate in terms of making sure we have the appropriate systems and administrative procedures in place to ensure that we can meet these requirements.
But yet, as we look at this problem, we discover that there are significant gaps that have yet to be addressed and we feel that it is most appropriate to address them in the sense of standards, data interchange standards that the industry can follow rather than to be dealt with on a case by case one-up basis.
So that's the basis of our testimony and we'll try to cover some important topics and where we see gaps remaining in terms of implementation of security privacy standards for HIPAA. Hopefully, you all have in front of you a copy of the testimony. It's ten pages and as I mentioned, these comments focus on key provisions of the HIPAA privacy regulation which is now final and the HIPAA security regulation as proposed.
While much has been made of the data interchange requirements related to HIPAA transactions and code sets, there has been relatively little focus on inter-application interchange requirements related to privacy and security. Although it may be conceivable to devise interchange/interface implementations on a on up, site by site, interface by interface basis, there is a far greater advance in adopting industry standard specifications for these purposes.
This submittal focusses on the health care provider enterprise. It describes the need to devise and implement standards=bases interchange solutions uniformly across all applications in the enterprise, enabling a common HIPAA privacy and security infrastructure, and ideally enabling a single point of administration.
Section 1 of my testimony characterizes a typical healthcare provider enterprise, including sources and points of access, data stores and interchange points for individually identifiable health information.
Section 2 outlines key objectives for full implementation of HIPAA security and privacy provisions uniformly across the provider enterprise with a single point of administration.
Section 3 describes in tabular form interchange requirements to enable a common enterprise-wide infrastructure, fully engaging, and uniformly implementing HIPAA privacy and security across all applications in that enterprise. The table shows where interchange standards exist, where draft standards or implementation guides are in progress and/or where substantive gaps remain.
I'll continue on Page 3. The Typical Healthcare Provider Enterprise is comprised of multiple sources and points of access of and for individual identifiable health information, including applications serving various functions within the enterprise.
For example, clinical point of service applications, automated devices such as: instruments and monitors, hand held personal access devices, fixed workstations, department and function oriented applications, electronic health record applications, work flow applications, decision support applications, administrative and patient accounting applications, data warehouses, mediators such as interface engines and the list, of course, goes on.
Within this enterprise, there are multiple application data stores, each maintaining individually identifiable health information which is the individual health record or some subset thereof. There are multiple points of interchange for individually identifiable health information within the enterprise between applications and between applications, devices, and workstations and, of course, this list could be extended.
There are networks interconnecting multiple applications, devices, workstations and interchanging individually identifiable health information. Speaking specifically about intranets which would span the enterprise extranets which might connect business associates of the enterprise and, of course, the public Internet.
Going on to Page 4, Section 2, what are the key objectives for the healthcare provider? Most of these are fairly straightforward and very familiar to all of you. I'll try to run through them briefly.
Obviously, there's uniform engagement of all applications within the healthcare provided enterprise in a common privacy and security infrastructure and encompassing for individually identifiable information all sources and points of access, all application data stores and all points of interchange.
In terms of privacy and confidentiality, we are protecting, obviously, individually identifiable health information in designated record sets as per the privacy regulation. We have objectives in terms of accountability, particularly in terms of accountable parties such as organization which may be providers, health plans, etcetera; the business units of those organizations, including department services and specialties; the individuals who practice within that organization, practitioners, caregivers, and other users who are also accountable for their use origination of individually identifiable health information.
There is an accountability aspect in terms of accountable agents recognizing that parties or organizations, business units, and individual agents or software such as application software such as mediators, interface engines, for example, and also devices which include instruments and monitors.
Accountability in terms of accountable actions relates to health services. For example, the provision performance and completion of health services. Accountability comes into play primarily in terms of HIPAA with health records containing individually identifiable health information and starting with the origination or authorship of that information continuing through transcription, amendment, verification, translation of content, access/use, disclosure and transmittal, receipt, the identification, archive, and destruction of the record.
Another objective is obviously accountability and traceability which includes other accountable actions by accountable parties and agents and also audit review tools. HIPAA has provisions for authentication starting with user-authentication which is evidence of individual identity, data source origin authentication which is evidence of authorship, origination and amendment, data validation authentication which relates to evidence of verification of content originated by another party or content originated by a device such as a monitor instrument. And then there's data interchange authentication which relates to the transmittal and receipt of information across the communication connection.
Another objective of HIPAA is data integrity, but you'll notice, there is a complimentary relationship between the requirements for data integrity specified under HIPAA which basically involve persistence and non-alterability of data and data integrity requirements that come from JCAHO which basically are described as or defined as data accuracy, consistency and completeness.
Another objective of HIPAA in terms of the healthcare provider is a chain of trust which basically tracks information from its point of origination, point of service, point of care to its ultimate point of use, point of report, point of claims submission.
Looking at this infrastructure requirement for the healthcare provider. Basically, we're looking for a single point of administration. In terms of configuration and control, a registry of security policy domains within the organization, registry of application functions which may access individually identifiable health information, registry of the health record itself and where its subsets are located, registry of accountable parties, agents and roles, security classifications for application functions, security classifications for health records, security clearances for healthcare parties, agents, and roles.
And we're also looking for, as part of our infrastructure, a single point of HIPAA inspection and review which includes audit review, for example, chain of trust audit events, data state audit trails, tracking data from its initial state and through each subsequent amendment. We're looking for an audit review which will allow us to look at security audit events as well as message transmittal and receipt events or logs.
Also, in terms of inspection review, we have an interest as part of our infrastructure in making sure that privacy notices are appropriately distributed, that individual consents for use are tracked, that individual authorizations for disclosure are tracked, that we have individual disclosure logs for the health record, and that we can track amendment requests as well as amendment denial recordkeeping.
Going on to Section 3, I'm going through these items again in greater detail. If you'll notice on this it's basically a two-column format. The first column specifies the requirement. The second column specifies the interchange standard which may enable that requirement. And as you'll notice, there are a number of areas where gaps remain and that is noted by the question marks in the right-hand column.
Our first requirement is a master registry of security policy domains which allow us to define discreet domains within the health provider enterprise, each with a unique security policy. And these may coincide with physical locations or business units within the organization, including facilities, department services and specialities. Obviously, for that domain we have to have some way to interchange the application function, the application function associated with that domain and the classifications for use, security classifications for use of those applications, the health record in that subset which may be pertinent to that domain and the classifications for its access and use, and also accountable health parties, agents, and roles which exist within that policy domain.
Our second item is the master registry of application functions which obviously is fairly straightforward, but basically those application functions which are involved in the origination, amendment, access, use, display, translation, disclosure, transmittal, receipt, de-identification archive or destruction, etcetera relating to individually identifiable health information. We want to enable this across the enterprise as well as within the security policy domains and also to include equivalent or comparable functions which may exist in multiple applications within that enterprise. So our interchange requirement then, of course, is security classifications relating to application functions.
The third item is master registry of the health record and its subsets which is a registry of the health record in its logical subsets which may, in the case of HIPAA, correspond to designated record sets, each containing individually identifiable health information identifying each discreet data store within the enterprise and including legally sequestered subsets such as psychotherapy notes, information obtained from confidential sources, etcetera.
Obviously, there are security classifications associated with the health record and its subsets, the subsets or the health records itself may also be contained in paper form so it's not just electronic versions that might be tracked through this process. But you will notice again that we have a gap on the standard side for that requirement.
Our fourth requirement is a master registry of accountable healthcare parties, agents, and roles and the corresponding security clearances for each. These are parties and roles accountable for the origination, amendment, use, and disclosure of individually identifiable health information and parties and roles accountable for the provision, performance, and completion of healthcare services and agents accountable for the origination, translation and translation of individually identifiable health information.
And we've gone through this before, organization business units, individuals who are introducing roles here which are specific roles that individuals may take in the course of performance of their duties within the organization and obviously agents are software and automated devices.
In terms of our interchange requirements, we need to be able to interchange the accountable organizations, the accountable business units, the accountable agents, and their related information. You'll notice that we have begun to fill in some of the standards requirements in HL7 v We have, for the first time, the ability to exchange identifiers, demographics, licenses, and credentials for individuals.
But you'll see that list is not complete in the sense that we also have to look at what authorized roles that person may fill, authentication details and visual certificates for that individual, clearances for application function access, clearances for information access and use. Those are areas where gaps remain. And also, of course, the interchange of accountable role information such as the ID of the role and clearances for application function and access and information access related to that role.
Our fifth item relates to authentication and, again, we are long on requirements and short on standards which might enable those requirements, at least in terms of being identifiable industry recognized standards for HIPAA implementation.
Now we have user-authentication, data source origination authentication, data validation authentication, and data interchange authentication the last of which there is now a multi-SDO taskforce which is being coordinated by ANSI HISB which is beginning to come to terms with data interchange authentication or message authentication in terms of assuring that the message received is the same as the one sent, and making sure that there is a way to authenticate on the receiver side who transmitted the message and on the transmitting side who received the message.
The sixth item is our chain of trust basically enabling trusted information flows including audit trails associated with those and that ensures auditabliity and traceability in terms of the flow of individually identifiable health information from its point of origination to its point of use, point of disclosure, point of report or point of claims submission.
And if we look at the key points in the chain of trust -- we talked about these before -- origination, amendment, verification, translation, access, use, disclosure, transmittal, receipt. We have a category here for convergence which is basically taking records and aggregating, summarizing or deriving information therefrom, point of record, de-identification, record archival, and record destruction all of which need to be supported by data interchange standards where none are adequately in place today.
How am I doing on time?
MR. BLAIR: Could you maybe wrap-up in about 2 or 3 minutes?
MR. DICKINSON: Okay. I have two pages to go.
Audit trails for data states allow us to ensure data integrity in terms of its persistence, permanence, and unalterabliilty where we essentially record the state of the data when it was originally captured and then we subsequently record its state as amendments or translations to content occur. Again, we have an informative ballot which is pending in HL7 that begins to address or actually should, in its final form, address these issues.
Audit trails for security events. Obviously, this relates to successful sign-ons and unsuccessful sign-ons and various kinds of system faults and so forth that may be reported in a security event audit trail. This too presumably will be part of the uniform ballot coming from HL7 on this topic, the topic of audit trails.
Under HIPAA, we have requirement for sequestered record sets and how they might be transmitted across the wire. This would include obviously, psychotherapy notes, information from confidential sources, information pertaining to legal actions which may be sequestered in special ways according to the HIPAA requirement. Again, we do not have interchange standards in place to enable this particular requirement at this point. Notice of provider privacy practices and a notation of the patient's receipt of the privacy notice. We need interchange standards in that particular area.
Going on to the last page, we have a need to interchange consents for routine use of health information. We have a need for standards to document the authorization for disclosure of designated record sets for particular purposes, gaining the permission of the patient for those things, and obviously including the purpose for such disclosure, the names or identification of those who are authorized to make the disclosure and/or receive the disclosure and any special expiration dates or events which might be pertinent.
And then we have a large and potentially onerous requirement related to recordkeeping associated to denial of amendment requests and there are basically four different things that might come into that denial. The first of which is the patient's request for amendment initially. The covered entity, of course, may deny that amendment. The individual may issue a statement of disagreement with that denial and the covered entity may rebut that statement of disagreement.
So basically, there are four different pieces of recordkeeping that are required in terms of HIPAA privacy and which must be attached to the record to which the amendment was requested and has to somehow be carried forward from that point in time anytime that record is interchanged. So again, we have a gap in our interchange standards in that area.
Thank you very much.
MR. BLAIR: Thank you, Gary.
Dr. Huff?
Jeff, while we're waiting, there's Billy Yasnoff. Are going to have time for questions at some point?
DR. COHN: Bill, what we're going to be doing is having everybody give their testimony. Probably by that time, we'll be ready for a break and after that, we'll get into questions and discussions for the remainder of the morning.
MR. BLAIR: Essentially, we have the morning for this particular panel.
DR. HUFF: Thank you. I'm very happy to be here today. I think these are tremendously important issues that we're discussing and I'm happy to have an opportunity to come and participate. The slides that I have cover the same outline as my written comments and so there's some small differences, but overall, it's the same information.
MR. BLAIR: Let me make sure that Kepa is able to hear you.
Kepa?
DR. ZUBELDIA: It would help if he speaks closer to the microphone.
MR. BLAIR: A little closer, please.
DR. HUFF: How's that?
MR. BLAIR: That better, Kepa?
DR. HUFF: Can you hear me now?
MR. BLAIR: Kepa, can you ---
DR. ZUBELDIA: I can't hear anything now.
DR. HUFF: Can't hear anything?
Apparently he can't hear.
(Microphone adjusted.)
MR. BLAIR: I'm prone to making these silly jokes, but here's a Committee and one guy is blind, one guy can't hear, and Clem can't speak.
(Laughter.)
DR. FITZMAURICE: Bring in the elephant.
DR. HUFF: Okay. You've got me wired in a different way now so hopefully that will work.
Just, again, note that I'm a clinical pathologist by training. I work for Intermountain Healthcare, the Chair of HL7, professor at the university, and Co-chair of LOINC and advisor to the SNOMED Editorial Board.
Again, very briefly, Intermountain Healthcare is a 22-hospital healthcare provider in Utah and Southern Idaho and the reason I bring that up is that we're directly involved in the business that we're discussing today and one of those institutions that would be impacted by the decisions that we make.
We have tremendous number of ancillary systems and patient care systems, all of those kind of systems that Gary was talking about in his presentation that are interfaced together, trying to provide an electronic medical record for our patients. That amounts to a data dictionary with roughly a million or half million concepts. We have sixty different kinds of interfaces.
Most of those interfaces are HL7, X12, and DICOM interfaces. Those are sixty different kinds of interfaces and then there are like over 500 interface instances. So, actually point-to-point interface instances with the institution and that results in somewhere around 900,000 transactions or individual pieces of patient data that get added to our electronic medical records each day.
So from that context, then, I'd like to jump right in and talk, give a brief introductory comment. These are comments from Wes Rishel that I agree with and that present, I think, a general feeling about this area.
We can't overemphasize the benefits to society of having a fine grain structured standard for exchange of clinical data. The idea that Wes has put forth on different occasions is the difference between irrational rationing, which, I think, is close to what we have today where we ration healthcare resources based on political lobbying and/or Madison Avenue.
The idea that we don't have detailed data, and, in fact, these kind of fine grain structured standards can lead to having the data to do rationale rationing. So we understand what happens to patients, we understand how they're being treated and we can then appropriately allocate with that knowledge.
The second statement is that the costs to do this are going to be substantial and that relates to the fact that it requires software to be implemented that is not yet implemented; it requires the creation of implementation guides; it requires vendors to modify their software and go through a revision cycle. So the costs are going to be substantial.
That leads to the next assertion which is that the benefits to society don't in and of themselves justify investments by individual organizations to restructure their systems and procedures. And so, the fact that there is great benefit to society does not necessarily mean that there's individual benefit to organizations in this.
And that leads then to the conclusion that really to recognize the value of these things, at some point, you do have to mandate, I think, the use of these standards. And at the same time, recognizing all of the difficulty and the costs, what we want to do then is rely on modest advances to existing standards to accomplish this. Otherwise, the cost is going to be out of -- inappropriate for the benefit.
And so it's critical, therefore, that even though we're going to lead to a mandate, the standardization needs to be evolutionary and provide time for organizations to achieve returns on their investments as they pass through the evolutionary stages of adoption. I think that Wes is so systematic in his thinking, I think this proceeds very logically and, in fact, is the basis for the rest of our comments.
So, jumping in. The comments on criteria for selection of standards. What I've basically done is slightly reworked the set of criteria that were listed in the proposal. My first statement is basically that we need to improve the efficiency and effectiveness of healthcare and the standards we chose have to do that.
So there has to be an unambiguous sharing of data and information, there has to be data to secure the integrity, a lot of the issues that Gary was talking about.
Interoperability, certainly that's our, but is extremely difficult to achieve completely. Unambiguous sharing of data and information may be the best we can do for a while and as we continue to pursue real Interoperability. We have to use standards that work. I think we can only select standards that are implemented and working in a wide variety of production clinical environments. If we don't do that, we take tremendous risks. There are so many good ideas that when they're actually in production don't work, that we can't risk creating new standards or adopting standards that have not seen widespread public production use.
We need to be cost effective in the standards that we select and chose those that are going to be the least costly to implement. That means that we need to strongly base this on market acceptance. Use what people are already using. We need to be sure that there are public domain and commercial tools that will support and implement these systems, that education and training is available and a lot of other things that are kind of the practical parts of implementing systems.
We have to have sustainable standards. There has to be a stable organizational support. So there has to be consensus participation in those standards.
Finally, we need to manage change. There has to be a way to flexibly respond to new requirements, be able to make timely corrections and enhancements and also to preserve business knowledge in the face of rapidly changing technology. And a lot of that ties back to then having a formal process, having a formal information model and being able to transfer that knowledge version-to-version so that that information isn't lost as new versions of the standards are created.
Changing then to comments on the questions for the standards development organizations. Overall, I didn't see any questions that were inappropriate. I thought all of the questions that were posed were appropriate. I suggest that the following questions be added.
Again, focusing on non-implementation --
(Question by reporter.)
The following questions that I would suggest be added: What public domain tools are available for assisting in implementing the standard? What commercial tools are available for assisting in implementing the standard? What kinds of training materials, tutorials, and other kinds of education about the standard are available? And includes technical training. Technical training being: What is the standard; how does it work; what are the fields; what are the meaning in the fields? The practical training is: How do you really implement? And that means what programming tools you use? What's the environment? Who can you buy software from? All of that sort of stuff, very practical kinds of things.
And then this may seem like a bit of a nonsequitor, but another question, I think, that really is pertinent to ask is to what extent can the standard serve the needs of veterinary medicine? And the reason I say that is the strong connection between actual and most notably with hoof and mouth disease, things that are going on, the tight connection between some of the animal biology and medical information and human medical information. And I think that's an area that we need to consider as we think about this.
The last thing in terms of questions for the SDOs, in previous trying to respond to these kinds of questionnaire it's a question of especially, for instance, for HL7 which has a whole suite of standards to know whether to respond for HL7 or whether to respond for each question domain.
And I would suggest that the Committee give some guidance in that regard so that people do this in a uniform way and how to respond to the questions. And my proposal would be that the people respond to the questions per domain and they would use, for instance, the proposed transactions as a guideline about that.
So, for example, HL7 would submit questionnaires about ADT standard. In other words, non-medication orders, standard results, then medication orders, etcetera. IN doing that, we may end up with some redundancy in the statements, but then you'll know exactly what the information pertains to.
If it was filled out at the level of all of HL7, a given standard could be -- a given part of the order could be used greatly and some other part not so greatly and if it was all answered as one question, it's very difficult to understand what it is. And so I would just suggest that the Committee give some guidance that these things be fairly fine grained in defining the particular set of the standard that's in use in being addressed.
Then addressing the priority of the proposed transaction list, I changed the order a little bit and added in three items that I think are worth considering. The priority then as I've suggested is ADT, then standard orders which really means non-medication orders that clinical lab, anatomic pathology, radiology, ancillary services. And then standard results, in-patient medication orders, clinical documents, and then I've added one, chief complaint, problem, diagnoses. And that seems critical to me for a lot of interactions and things that we're trying to achieve. Then, images. I've added another new one which is visual integration and I didn't know exactly where to put this. In a sense, it's in a different dimension. It's not a message standard in the traditional way that we think about it, but within our institution, we found increasing value in visual integration technology.
What it does it makes information available by showing context for that information. And I think Bob Seliger will address that further. So I won't say much more here, but I think it's an important area to consider.
Then the next item was data from bedside instruments and monitoring systems, orders for outpatient medications to pharmacy systems. Then I've added another new one, procedure scheduling, which, again, in our institution is very important understanding when a person is going to have surgery or endoscopy or other kinds of procedures.
And then the charge capture information to billing systems and I would just emphasize that charge capture, this is not overlapping with the other HIPAA financial transactions which are actual bills. This is essentially saying that this is something that happened to the patient that is a billable item, sending that to a billing system which would then send out the HIPAA transactions about that information.
Finally, my additional comments. On thing that I would say is that we're not at a state with any of the clinical standards that I know of that they would really achieve the level of unambiguous data exchange that we want. That implies that there will be a need for implementation guides.
We have, for instance, implementation guide for immunization which was done by the Centers for Disease Control. Many others need to be done. Laboratory orders and results, radiology orders and results, medication, microbiology, etcetera. So there's a lot of work that needs to be done.
In terms of the implementation strategy, and now I'm talking in the global sense, about how do we approach implementation of these standards in the real environment. I would see a first approach to this being a reward to those who supply data according to the standards.
And so actually, a payment per case and per case or per transaction that incentives people and alert doctors of the standards. Once you have proven success for a given standard or a given domain area, then you set a transition plan and you set hard dates for the beginning of the transition and an end date when all systems must need to be compliant.
That allows time then to develop implementation guides, technical training, practical training. And we should start in the best-defined areas. We've been passing this kind of data now for a number of years in the laboratory, radiology and pharmacy areas and indeed one of the reasons that's true is because that information is the information that's the highest in demand for clinicians and, in fact, would probably have the most impact too in public health as well as public reporting and sharing of data across health care enterprises.
So we end up then, only mandating the standards after initial implementation has been proven effective and we've had time to develop the infrastructure, education, etcetera that are needed to bring these things to fruition. Where to implement, which is a slightly different thing. The first thing I would say is we want to proceed forward and certainly support the reporting of clinical data with HIPAA claims attachments as currently proposed.
The next area, I think, that would be the most fruitful is reporting to governmental departments, offices, and agencies. So I think the infectious disease reporting to state and federal agencies, immunization information to state and federal agencies, tumor registries, the Food and Drug Administration for adverse drug events, Food and Drug Administration for clinical trials information, and HCFA chart review and quality of care assessments, I think, are all areas that would be the most profitable to send coded fine grain clinical information.
Again, bringing the idea of reporting of veterinary data to governmental departments and agencies. Again, I think it's critical and could provide tremendous value to have early reporting of veterinary sorts of data because of their pertinence to human health and well-being.
After those areas, I think the reporting of clinical trials data to private companies is a very good place to apply the standards. Reporting to national professional databases. Intermountain Healthcare has a number of these groups that we participate in and we would be helped tremendously by having standards within the area of cardiology, mother's and newborns, endoscopy, etcetera where we report to myocardial infarction databases, open heart surgery databases, prenatal care, neonatal care, birth defects. All of those things would be tremendously benefited by the use of standards.
Finally, I think the data exchange between health care enterprises so that the electronic medical record is truly shared and can be passed from enterprise to enterprise is appropriate to care for the patient. And finally, data exchange within a single health care enterprise. So it's roughly of where I think the greatest bang would come for the least amount of work and cost.
My final point is that we need to have a plan for evolution. We're going to need new versions of standards and we're going to need new standards that we don't have today. There should be a well-defined process for prototyping and implementing the next generation of standards in production systems before there's general adoption.
And that needs to be done in a way that it's not in violation of the regulations or other mandates. It can be done in a systematic way and then mandate their use after there's proven success.
That concludes my testimony.
MR. BLAIR: Thank you, Stan.
Is it Lynn who's next?
MS. GILBERTSON: Yes, that's correct.
MR. BLAIR: If you guys switch chairs on me, I won't know the difference.
(Laughter.)
MS. GILBERTSON: Kepa, hello. Kepa, can you hear me?
MR. BLAIR: Kepa, we'd like to know if you're able to hear Lynn.
He may have us on mute. So he may need a moment to respond.
Kepa?
Why don't you go ahead Lynn.
MS. GILBERTSON: Okay. We've lost Utah.
DR. ZUBELDIA: No, I can hear you now. Something was happening during Dr. Huff's testimony and I couldn't hear practically anything at all. Could somebody put the microphone in front of the speaker and make sure it's working?
DR. COHN: Lynn, why don't you try? Lynn?
MR. BLAIR: Lynn, try speak into the microphone a little bit and let's see if Kepa can hear.
MS. GILBERTSON: Good morning, Kepa. How are you feeling?
MR. BLAIR: Why don't you try the other microphone.
DR. ZUBELDIA: I can hear Simon.
DR. COHN: I know you can hear me.
MR. BLAIR: You hear Simon, but not Lynn.
MS. GILBERTSON: Kepa, can you hear me now?
DR. ZUBELDIA: I can hear you now perfect.
MR. BLAIR: Perfect. Good.
Kepa, what I think happened is that Stan was trying to use the fixed microphone and then move to a levelier and for some reason, it didn't seem to connect so well with you. We'll try it with the fixed microphone. So let us know how it works.
MS. GILBERTSON: Good morning. Once again, my name is Lynne Gilbertson. I am Director of Standards Development for the National Council for Prescription Drug Programs or NCPDP.
For those that aren't aware, NCPDP is located in Phoenix, Arizona. It's a not-for-profit ANSI-accredited Standards Development Organization of approximately 1300 members who represent computer companies, drug manufacturers, pharmacy chains and independents, drug wholesalers, insurance, mail order prescription drug companies, pharmaceutical claims processors, physician services organizations, prescription drug providers, software vendors, telecommunication vendors, service organizations, government agencies and other parties interested in electronic standardization within the pharmacy services sector of health care industry.
Draft Criteria for Selection of PMRI Message Format Standards NCPDP Response to this.
Section 1. NCPDP has identified the need for a PMRI as it would apply to pharmacy business practices and transitions. Our goal is not to develop a new standard but to work with an existing standard from an ANSI SDO and if necessary request modifications to their standard to meet our needs, unless those needs could not be met.
For the past few years NCPDP members have been researching and reviewing potential standards that may affect our needs. Areas of interest to pharmacy include: sharing of prescription information with other health care providers (including other pharmacies), allergies, lab results and diseases. NCPDP members believe that the HL7 standard is the best fit and our goal would be to work with HL7 to develop a standard implementation that would meet our needs and the needs of all Health Care providers.
We are currently looking very closely at an HL7 implementation being used by HealthNet in British Columbia. Healthnet has developed a Patient Profile standard that could be used as a resource to develop NCPDP's Patient Profile standard. Systems excellence, a software vendor in Canada and the US, has provided NCPDP with a copy of the Application Services Professional Pharmacy Services document, and the parts that were relevant to Patient Profile were reviewed within the NCPDP work group.
The group's goals are to decide on how the standard would take shape, whether it should be in HL7, NCPDP SCRIPT, NCPDP Telecommunication, or XML format, and to determine which parts of the HealthNet work would be most valuable. The group hopes to have these goals accomplished before the end of 2001.
As for the Interoperability, the exchange of information between computer systems is usually not the difficult piece. Agreeing on the data elements, the values, and meanings is the difficult piece. You must have a common language in which to converse. Code sets, identifiers, values are important; less important is the structure or the transportation mechanism. A common language is achieved by either defining one language, or providing a mapping/translation correlation.
As for the other items noted above in this Section 1, they should be considered as factors to the selection process.
2. Draft Questionnaire. The Information is there. This is being taken in NCPDP's Workgroup 11 which is the Prescriber/Pharmacist Interface in a task group under that being called Patient Profile.
The Patient Profile group is meeting and working on draft paper as well as reviewing the documentation I mentioned earlier from HealthNet. They are planning to complete the documents in the 2001 time frame.
For the General Information questions under Section 2 Draft Questionnaire, NCPDP does not have applicable standards currently in use for PMRI specifically. NCPDP, an ANSI SDO, is responsive to the industry's needs using the Standard Operating Procedures to ensure industry consensus and approval processes.
Section 3. The Proposed list of PMRI transactions. Regarding Item Number 7 which is prescription information from provider to or from retail pharmacies.
Regarding Item 7 - NCPDP has created a Prescriber/pharmacist Interface standard called "SCRIPT" for transactions from provider to/from pharmacies for prescriptions. SCRIPT is an ANS standard. SCRIPT supports new prescriptions sent from the prescriber to a pharmacy, refill requests and responses from pharmacies to prescriber, compliance transactions to notify the prescriber of a dispensing event to monitor patients using their prescriptions, and others. Therefore, we do not feel that this transaction or business function should be included in PMRI, but rather recognized as a standard for business functions.
NCPDP was not sure how #9, intra-institutional charge information, fits into PMRI, as this appeared to be a billing event, covered under HIPAA transactions. There was a request that maybe we add a very simple request that gives patient demographic information, pharmacy and medical allergies. Something very simple, straightforward.
As for the other transactions, we feel it is important to look at the business functions these may be separate business needs and therefore the standards should encompass those needs. And separate functions should be under different timeframes/schedules for expected implementation. PMRI should not be grouped into one timeframe unless analysis proves that all the business entities are tied together and need to converse.
4. Additional Comments or Critiques. NCPDP recommends a narrower approach. Healthcare industries cannot share all their PMRI information soon. A project that is too large will have problems. A possibility would be to choose specific business functions and develop the sharing of information electronically, and then add to the other business functions upon learning from those experiences.
A questionnaire is a fine start to getting the word out and getting information back. However, each response comes from a different perspective and may mean totally different goals after you peal away the highest layer. Example that Stan mentioned, different entities are going to answer the questions based on their perspectives.
A concern brought up is how the information would be managed/maintained? How is the sharing of updated information maintained among doctor/pharmacy/hospital/etcetera? Each of the standards must address how, when updated information is relayed to requester, what does their system do with it? Do they believe it or wait until they have seen the patient? What if differing sources give differing information?
Flaws or inconsistencies seen today in the paper or telephone world will not be fixed just by moving electronic. The foundation must be stable regardless of the medium.
I will recommend that this information be brought to the attention of the NCPDP members at the next Joint Technical Work Group meeting in May.
Thank you very much.
MR. BLAIR: Our next speaker. And identify yourself for me.
DR. BEHLEN: Yes, Fred Behlen.
MR. BLAIR: Thank you, Fred.
DR. BEHLEN: I participate in DICOM as a representative of the American College of Radiology. I'm also Co-Chair DICOM Working Group 20 and the HL7 Imaging Integration SIG: this is really the same group recognized by both organizations and functioning as a joint working group. I represent the University of Chicago Hospitals to HL7, and serve as a member of the Radiology basic science faculty at The University of Chicago.
I am pleased to offer my testimony based on this experience, but given the short timeliness it was not possible to develop comments through official channels, and so thus it should be stressed that all these comments represent my own opinion, and not necessarily any of these fine organizations.
This morning we will begin with some background facts about DICOM, what it is and how it works, and then develop a few points about the permanence of patient records which is one of the things I will focus on. And finally in that context address the four question areas for which testimony was solicited.
DICOM is a standard for Digital Image Communications in Medicine, whence comes its name. It's deployed in billions of dollars worth of equipment available from every major medical imaging equipment manufacturer. DICOM began as a joint effort by the American College of Radiology (ACR) and the National Electrical Manufacturers Association.
DICOM in its early versions was called the ACRNEMA standard. It is now, since the early 1990's, an independent international organization called the DICOM Standards Committee, which still enjoys a high level of support from the ACR and from NEMA, but also includes other commercial and professional organizations in its membership.
DICOM is an international standard, representative of the global market for medical imaging equipment. DICOM has Type 1 liaison status with the International Standards Organization, but the DICOM standard itself has not been submitted as an ISO standard.
The scope of DICOM is Diagnostic Imaging, as shown here, which is extracted from Part I of the DICOM Standard. It's a Venn diagram showing medical informatics as the universe. DICOM scope overlapping with administrative and his/risk and lab within certain area of operation.
DICOM defines image objects from ophthalmology, dermatology, pathology, endoscopy and dentistry, as well as cardiology and radiology. DICOM also defines standards for waveforms, including electrocardiograms and electroencephalograms as well as audio. While there are other standards for waveform, DICOM is unique in its ability to unambiguously synchronize waveforms with medical images, as is needed in cardiology.
But, Diagnostic Imaging is not all images and waveforms. We get patient identifying information and orders from outside the imaging department, and we have to return reports to the referring physicians. Thus, DICOM also includes facilities for reporting and for workflow management.
It's been well recognized that integration of imaging workflow with enterprise patient care processes is essential to the efficiencies that digital image management promises and hasn't always delivered. Thus, a large multi-year demonstration project has been jointly undertaken by the Radiological Society of North America (RSNA) and the Healthcare Information and Management Systems Society (HIMSS), which brings together vendors to connect, test and demonstrate the interconnected systems under a number of use case scenarios.
The project, called Integrating the Healthcare Enterprise (IHE), has completed year two of its five-year plan. Their implementation guide, called the IHE Technical Framework, is not really a standard but a recipe for a
tested configuration, which reduces the optionality in interfaces and provides for a smoother implementation and let's people have a way of specifying what it is they want to buy. I like to think that someday, HHE or someone like them will go on to develop implementation recipes for other areas like laboratory, bedside monitoring and other interfaces.
Like other standards, DICOM defines both messaging services and information objects. Information objects may be either Composite or Normalized, and there are separate message services for each type.
MR. BLAIR: Fred?
DR. BEHLEN: Yes.
MR. BLAIR: Just wanted to kind of indicate if this is preliminary or background to your critique of our process and that is appropriate, but we're not at the stage now where we'll be evaluating a specific standards for selection. We're really looking for your critique of whether or not we have the right criteria, the right questions or the right domains.
DR. BEHLEN: Great. Thank you. I will cut to the chase soon.
There are both information objects and message services that handle those. And I think the key point I wanted to make in pointing out these separate objects and standards is that in DICOM there's a certain separation between information objects that are permanent to be stored, the composite information objects and information objects, so-called normalized objects that are virtual things that exist inside of databases. And these are things that can be created, deleted and selectively modified using the message services. But it's not the kind of persistence you see with composite objects.
Over the years of DICOM implementation experience, we have found the widest vendor and market support for the basic composite objects and services that support acquisition, storage and transfer of medical images and waveforms and with today's growing interest in workflow management, together with the IHE demonstration program, we've increased the use of normalized services but the use of the storage of these physical chunks of information has really been the heart of DICOM's implementation.
Let me jump ahead here and make one final point here that. Within DICOM also defines the storage of these information objects on media. So it's not simply a messaging interface, but there really are standards for how these things are stored. And this is the thing that I think is very important to the data permanence issues that I'll move on to right now.
Medical records have to be kept for a long time. Maybe not as long as the Rosetta Stone or the Torah in this life, but they do have to be kept for a lot longer than the lifetime any computer systems that store them. Thus, any system storing medical records must provide for migration of data to a successor system, and to the successor system's successor. But how is all this accomplished?
Well, the systems we have today are connected by messaging standards, and the actual media formats are not necessarily available to the user. This is true for DICOM archives, and in Relational Databases this arrangement is even enshrined in the Foundation Principle in the rules for a relational. It's basically you don't worry about the storage format, you just focus on the messaging.
To migrate the data, one hooks up the two systems and transfers it, one to the other, through the messaging interface. If you've tried this with any two databases know that this is not a simple plug-it-together-and-throw-the-switch type of operation.
While you're doing this, both systems have to be housed, and staffed, and maintained while the transfer goes on. It can take a long time if you're transferring a few thereabouts of medical images. So it's not really like preserving written records so much as it is like oral tradition.
The sage and youth sit down and accomplish the intelligenerational transfer of information, and both must be supported while the transfer takes place. This slide shows Homer reciting in this Fresco by Raffle.
By the time Hippocrates came on the scene in the late the century BC, the Greeks were already writing things down, and some of the detailed case histories he recorded have survived even today through transcription. This slide is Gaelen at the bedside with a dedicated transcriptionist. We don't have that sort of thing today. You can tell it's before managed care.
(Laughter.)
The point is that the great advantage of written records is that you can transfer them to the next generation even when after the sage is dead. Is there a way we can bring this kind of progress to electronic medical records? If you standardize the storage of the information, if you have a way of standardizing the storage and it's stored in discreet information objects, and if the format of those objects is standardized, then you can transfer the data, the stored data and reconstruct the database. Fortunately, that's what we're able to do with DICOM. I know firsthand that's how we did it in a PACS archive migration at the University of Chicago.
To accomplish the same thing for computer-based patient records will require standards for stored patient records. There is encouraging progress in this direction at HL7, where the first level of the Clinical Document Architecture (CDA) has become an ANSI Standard.
Through the joint working group, we have been working with HL7 to maintain compatibility between the CDA
documents and DICOM information objects. So we can do mapping on a container-by-container basis.
The conclusion from my experience in using DICOM is that it a worthwhile investment up front to identify and keep separate or at least think separately about the issues of transient data separate from the kind of data that we need to keep. It serves not only the longevity of the data, but also the integrity.
You know if the patient's record comprises N data objects, and you have transferred all N of them, then you can say that you have transferred the complete record and you can do that kind of thing in a database-oriented record, but it's a more complex test to define.
In this context, the following comments are offered in response to the "Draft Framework". The criteria questionnaire and transaction set I think are all reasonable and well thought out, but I do have some concerns about the scope and degree of specificity of this selection process.
I'll return to the general remarks later, but first, let's look at the individual ones. The criteria for selection are certainly valid, the Interoperability, data comparability, data quality, accountability and integrity, market acceptance, consistency with other standards, identifiable cost, timely standards and flexibility.
Although it is difficult to say how one would measure and weigh these criteria to "choose" a standard to recommend under HAPPY. If this is intended to be a prioritized list, then I would put data quality near the top. If different medical records use different vocabularies or different measurement units, in principle you can translate those things later on, but if the data if collected inconsistently or if records are missing or corrupted, there is little you can do.
The questionnaire covers a good set of quality measures for a standard, but is missing questions about data permanence and data migration. The questionnaire should ask how systems implementing the standard can migrate data to future systems; how loss of information content in multiple migrations over many years can be avoided; and the standard should have a way of defining completeness in transfer of a patient's record.
Also included should be whether the standard specifies a storage format for archival data. If the standard includes a storage format specification, is it based on a general-use file system or standard-specific media? In other words, if stored data is to be transferred from one media form to another, can you do this with generic file-copying operations or do you need a custom applications programs specific to the standard in order to read the media?
It's a good questionnaire, and I believe the results of the survey would certainly make an interesting journal article. The government has some unique advantages that will help it obtain a high response rate to the survey. I believe the survey and the analysis of the results may help the DHHS to plan an approach to promoting standards for PMRI. But I doubt that it will directly lead to a selection of a winning standard.
The proposed transaction set is reasonably complete. One change I would propose is that "radiological images" should be expanded to include "medical images and waveforms", as images are also produced in endoscopy, pathology, dermatology, cardiology and a host of other disciplines.
Images and waveforms produced in diagnostic procedures are part of the evidence on which diagnostic results are based. The results are part of the medical record and have to be retained for very long times. In other words, the diagnostic results, the reports have to be kept for a very long time.
But, generally speaking, the images are subject to short retention times. We will have to be aware that as images find their way into reports, depending how they are referenced in the text portion, they may become part of the medical record and subject to longer retention requirements of the medical record.
The stated topic, "... Selection of PMRI Standards" needs to be clarified I think with respect to the specificity of the planned selection. Is the goal to specify a fixed set of transactions and select a single "winner" for each transaction? Or is the goal to select a number of Standards Development Organizations to work with in converging on a set of interoperable standards?
I would hope and recommend that the latter approach be followed. The process is not as simple as defining the transactions and selecting the best standard for each. I think the actual terrain of healthcare standards does have some areas of contested turf, but for the most part the various standards occupy different application domains. Thus, the hard work before us is one of bridging between these standards, and interfacing between systems serving these application domains. In other words, it is not that there are a lot of viable, acceptable and tested standards available, and that the DHIS needs to choose the best ones. There is, in fact, a lot of standards work that remains to be done. In most of those areas where the standards are mature and well matched to application needs, those standards are already almost in universal use, as is DICOM for interfacing to imaging devices.
In areas where obvious standard solutions are absent, I think if we look, there are more gaps than overlaps between standards. Needless to day, I think standards are important. The Federal Government can help.
In the written comments, I also offered a few remarks that we would certainly benefit by a little assistance in the form of encouraging provider involvement in standards. It's one of the things that is short is that there's a paucity of people who actually spend their times in the trenches in provider organizations.
However, although the standards development efforts can certainly use some help, enabling some acceleration of the process. Even though they can use some help, the vine can be killed by too much watering. The key reason is that pressure to achieve rapid consensus yields too much optionality, which is the enemy of Interoperability.
Let's look how that works. This little Venn diagram shows three vendors coming together to define a standard. Their data elements overlap as shown. They can agree on the things in the intersection, but the only way to get consensus immediately -- everybody's got 5:00 o'clock flights out and we've got a lot of pressure to get consensus -- the only way to get consensus immediately is to make the standard encompass the union of all three sets, and the only to do that is to make everything outside of the intersection optional.
If you rush the process, that's what you get. So high Interoperability requires little optionality, and that often takes many rounds of negotiation and use case review. In the SDOs we need help, but there is such a thing as too much.
My recommendation would be in terms of scope my recommendation would be that the NCVHS narrow the scope of PRMI standards selection at this point, focusing on transactions sending results to the permanent patient record, and administrative functions managing results within the permanent record, things like merges and so forth.
Once standards have been selected, profiles or templates need to be defined to improve Interoperability within each standard implementation. This in itself is quite an ambitious project, and is the one that has the greatest long-term impact.
In the meantime, one thing that we can do even if nothing else happens is that implementation of HIPAA claims requirements will have effects on implementation practice that will ripple through the healthcare system, in ways that I believe will be hard to predict, and I believe it would be beneficial to wait for these results before attempting to standardize the many transactions handling transient data in the healthcare process.
In evaluating standards for transactions involving electronic health records, I would note that we should also take note of the overseas efforts in CEN in Europe and GEHR and the good electronic health record effort in Australia. These groups have made significant progress, and their experience bears some attention.
And finally, coming back to the point stressed earlier, standardization of storage formats as well as message services is a powerful asset in the maintenance of long-term records.
Thank you.
MR. BLAIR: Fred, thank you.
Let me do this because we're running a little short on time. I think many people probably need a restroom break at this point. If we take this break and if we could limit that to about 10 minutes.
DR. COHN: Let's take a planned 15-minute break.
MR. BLAIR: A 15-minute break? That's going to be until 11:00 and I then I believe we have two more testifiers, is that correct? And if they are able to do their presentations within 15 minutes apiece, that will bring us to 11:30. That will allow us 30 minutes for questions afterwards. So let's try to see if we can stay on that schedule.
DR. COHN: Mike was raising his hand.
DR. FITZMAURICE: I've been very impressed with the quality of the testimony so far and I think the rest is going to be no exception. I wonder if the presenters would also share their PowerPoint slides with us. It's impressive that you've condensed it down into specific bullet points and I detect some additional thoughts and comments that weren't in the written testimony. If so, would you please then share them with Jackie Adler, who is over there standing up with her name tag in her hand?
DR. COHN: Gary, did you have a question before we break?
MR. DICKINSON: My concern is I need to leave by 11:30.
(Break.)
MS. KRATZ: On July 6, 2000 report to the Secretary on "Uniform Data Standards for Patient Medical Record Information focuses on terminology and current message based standards to address the complexity of viable engineering solutions to support electronic health record systems. Although these areas are key elements of electronic health record systems, feasible systems require a broader focus. Let us further explore the reasons for this.
Today's network capabilities demonstrate that it can provide high-performance service for digital video, remote haptics, and remote control of medical devices instrumentation. However, the overall network doesn't today routinely provide instructors, clinicians, and researchers with performance sufficient to support network-demanding applications such as video-conferencing and large-scale data transfer. Bottlenecks and problems exist at a variety of points along the end-to-end network path between a local display and a resource at the other end of the connection.
A predictable experience is required for medical applications. The challenge is to provide standards electronic health record systems that are powerful, but not time consuming and coordinates the amalgamation of interoperable computing resources necessary to complete healthcare business processes. It is not only important to consider data quality but also quality of service requirements for PMRI standards.
End-to-End Performance issues must also be considered. Setting data standards, classification and coding standards, messaging standards and information storage standards for the PMRI will not adequately address the broader end-to-end performance issues that must be addressed to enable a deployable national electronic health record.
The Big Picture, and my apologies to Mr. Blair, but this is a very important diagram. It is referenced from the Numerical Aerospace Simulation systems division at NASA Ames Research Center. If I might go through the different components of it for the benefit of Mr. Blair.
Consider the various components of the Information Power Grid as cross-functional requirements critical to provide end-to-end PRMI standards. Potential cross-functional criteria for PMRI standards include system users. System users need computation to accomplish a variety of business processes.
In my experience, Human Computer Interaction (HCI) requirements are left to vendor solutions. The standardization of information representation to human users is generally not addressed by healthcare standard development organizations.
Recent developments in the XML community may positively impact the medical domain, such that consistent representation of electronic health record data may be accomplished in the future. The PMRI report references the need for HCI, but it is not factored into the criteria for the selection of PMRI standards.
Intelligent Interfaces provide a knowledge-based environment that offer users guidance on complex computing tasks, and provide for data capture. Interoperability and data comparability are provided via message-based standards; however, they rely on ASCII streams of text and only work well for message-based technology mechanisms.
As the market has proven, this works extremely well for Interoperability between two legacy healthcare applications, and data comparability may be proved through standard vocabularies and implementation guidelines. However, technology has evolved forward and the need to create redundant stores of information on multiple application systems is no longer required or feasible. Data synchronization becomes impossible to operationalize, with data quality and data integrity inconsistencies resulting from application dependencies. Standard application programming interfaces (API) provide functional semantics for intelligent interfaces.
Middleware provides software tools that enable interaction among users, applications and system resources. Internet2 defines middleware as "glue" or a layer of software between the network and applications. This software provides services such as identification, authentication, authorization, and directories.
In today's Internet, applications usually have to provide these services themselves, which leads to competing and incompatible standards. Standard interoperable middleware services make networked applications easier to use.
Today's healthcare delivery systems utilize message format standards to achieve Interoperability via message based middleware mechanisms. However, the notion of object oriented software component services for Interoperability between systems is not addressed in the PMRI Report, and should be included in the criteria for PMRI standards.
Operating Systems add another component of complexity to the coordination of interplay between user applications, computational resources, network and data storage. The PRMI standard selection criteria addresses operating systems through "flexibility" requirements in response to new OS developments.
End-to-end performance and quality of service are greatly affected by hardware and software components on user
applications. Performance prioritization by application functions is required for optimum system functionality.
Supercomputing is an aspect that brings together heterogeneous collections of high performance computer hardware and software resources. One may ask about the relevance of supercomputers to electronic health record systems, one only need look as far as the advances in biotechnology and genomics to realize that access to computational resources should not be an oversight as criteria are set for PMRI standards.
Networking. Networking provides the hardware and software to permit communications among distributed users and computing resources. The Internet will continue to impact the healthcare industry well into the future. Multi-media electronic health records should be considered as standards are selected for electronic health record applications. Healthcare industry standards should leverage the utility offered by other industries, such at H.323 for video, to engineer electronic health records.
Mass Storage provides a collection of devices and software that allow temporary and long-term archival information storage. Data mining applications continue to evolve and with them growing concerns about inference of private information to unauthorized sources. A separation of concerns for information and functional semantics is a necessary criterion for PMRI standards. And we're done with the Big Picture.
Market acceptance is the next piece on the draft framework. Market acceptance requires more than simple percentages or statistics on the number of deployed standard system implementations. PMRI standard criteria need to address emerging business models for the information economy. Provisions for Applications Service Providers (ASP), Content Providers, and others, to support the business models of the information economy, Business-to-Business, Peer-to-Peer, ASP-to-Business, Business-to-Consumer, B-to-C, B-to-D, etcetera, etcetera. These must be addressed.
Message format standards simply do not support these emerging business models adequately. The PMRI standards criteria should not constrain the development of new market avenues of potential benefit to the medical domain.
The next area is the draft questionnaire of PMRI message format SDOs. First, the general information. The general information from the SDOs is appropriate as outlined in the draft questionnaire. Contact information at the end of the questionnaire should be moved to this initial area and a URL should be included in the list of contact attributes.
Number one, indicators of Interoperability seem to focus on customization of applications and implementation guidelines. First, a definition of implementation guide is required, as this varies from community to community within healthcare SDOS.
The issues of end-to-end performance are indicators of Interoperability and play into the customization issues identified in the PRMI report. Where formal conformance criteria are not available, best practice guidelines prove to be an effective mechanism to identify viable implementations.
Two, indicators of data comparability make an implicit assumption that coded vocabularies will offer functional semantics to enable data archive and retrieval. The questions are too prescriptive in the use of tables referenced by message structures. Criteria should be included to address object-oriented frameworks, or the criteria should be made more general.
Three, characteristics of data quality, accountability and integrity should address end-to-end performance criteria. Does any standard really accomplish data accountability, data integrity or improve data quality?
Measurement criteria should also be included. At a minimum measurement criteria should address the definition of a standardized set of comparable measurement criteria implemented on a range of platforms.
A survey of existing measurement, monitoring and diagnostic tools; rigorous documentation and analysis of core measurement infrastructure; identification of application architecture and system infrastructure based on implementation experience; iterative performance testing will identify patterns of success; advertise current best practices to relevant communities, as these become the basis for conformance criteria.
Four, indicators of market acceptance ask for simple percentages from a variety of communities. When the numbers are added up, I can pretty much guarantee that it will be greater than 100%. So, what are the useful indicators of market acceptance? It depends on the community you query. By targeting only a select community are the number really meaningful?
Five, consistency with other standards will likely bring forth an interesting array of Memorandums of Understanding and liaison relationships between various SDOS. This is all well and good. However, the questionnaire might address the ability to fast track a specification between standard development organizations to identify where SDOs are working together.
Six, identifiable cost asks about the cost impact of developing a standard, but it might also consider inclusion of costs (cost savings) to an organization for implementation of the standard. Return on investment (ROI) figures could prove telling.
Seven, timely standards development procedures should consider that standard organizations that deal in "Internet time" require standards to have a commercially viable working implementation; ANSI does not. PMRI candidates should provide reference implementations of the standards under evaluation, with associated tool sets and conformance criteria or best practice guidelines.
Another area addressed by many standard development organizations is a fast track or "Request for Consideration" (RFC) process. Commercial implementations that are defacto industry standards are expedited through the ballot process thus providing an avenue for commercially viable solutions.
Finally, eight, flexibility to respond to new requirements should consider broadening the scope to include a bit more "big picture" criteria for HCI, intelligent interfaces, middleware, operating systems, computational resources, network and mass storage as these all have dependencies for end-to-end application requirements.
The proposed list of PMRI transactions to be considered for HIPAA standardization recommendations does not take into consideration the business processes to be accomplished by an electronic health record system. It seems to begin by identifying existing standards, instead of the areas that PMRI standards need to address. Identification of workflow processes for electronic health record applications might provide a path to viable standard selection. Good starting points include user authentication and patient identification, instead of ADT transactions.
Additional Comments or Critiques. The Internet2 Health Sciences has formed a couboratory on Electronic Health Records, to address the requirements of complex academic health systems. This group is interested in working with an international collaboration, based on open source sharing of intellectual properties called Open E H R of Open Electronic Health Records.
Internet2 Health Science participants have evaluated a methodology launched by the European Community called the Good Electronic Health Record (GEHR). The information architecture of GEHR provides a set of principles governing the logical structure and behavior of healthcare record systems to enable communication of the whole or part of a healthcare record.
This architecture has been proven to allow various independent implementations of electronic health record systems in different countries. The communication model of GEHR is quite flexible and scalable. There is an open forum to share and discuss technical information.
The committee asked for an opinion regarding a broad versus narrow scope for the initial selection of PMRI standards. Contrary to my other panelists, a broader scope should be considered in the first phase of PMRI standard selection. By excluding appropriate standards, new business models and contemporary engineering advances may inadvertently be excluded from PMRI selections. This could prove detrimental to the industry.
My final comment is in regard to overall clarification of the document terminology. "Electronic Health Record" has growing international consensus as the terminology of choice when referring to Patient Medical Records, Computerized Patient Records, or Electronic Patient Record, etcetera. While one terminology is no more correct than the next, ISO TC215 has a specification in process on Requirements for an Electronic Health Record Reference Architecture, which recommends Electronic Health Record (E H R) as the terminology of choice.
In conclusion, I would like to thank the Committee for the opportunity to share my thoughts on criteria to be utilized for the selection of PMRI standards. The views represented in this testimony reflect the input of many individuals with a broad base of experience. I would be remiss to not acknowledge the contributions of Dave Forslund, Tom Culpepper, Sam Heard, Mike Gill, Ted Hanss and Steve Corbato to my increased understanding of the issues around electronic health records.
Thank you for your consideration.
MR. BLAIR: Thank you, Mary.
Steve, I think you are ---?
MR. STEINDEL: Yes, thank you, Jeff. The last member of the panel.
The Centers for Disease Control and Prevention (CDC) would like to thank the Subcommittee for Standards and Security of the NCVHS for the opportunity to present our comments on the issues of standards for Patient Medical Record Information (PMRI).
I am Steve Steindel, a Supervisory Health Scientist with the Division of Laboratory Systems, Public Health Practice Program Office, CDC and am addressing this subcommittee not in my capacity as a health systems researcher but as CDC liaison to several standards development organizations. In that capacity, I have had the opportunity to interact with many in this room, and also those implementing programs at CDC, concerning the need for standards that allow Interoperability -between systems.
CDC has a unique perspective on the standards process. In general, we are neither a producer nor a consumer of data. For example, we have responsibilities for protecting the public from infectious diseases, preventing chronic diseases, prompting healthy behaviors, preventing environmental exposures, understanding injury prevention, preventing workplace injuries and tackling toxic exposures. We perform most of these functions through our partners, generally at the state and local level, which are the true consumers of the data. Not only do we look for standards that function at the site of data generation, but we look for standards that will allow the information to transfer without change in meaning though the system. Eventually, this data reaches CDC programs where our epidemiologist perform their function of understanding the distribution and determinants of health-related states in specified populations and apply this knowledge to control the health of populations.
CDC has had years of experience in operating electronic disease reporting and surveillance systems. In 1995, an internal report discussed the inability of these systems to communicate outside of their limited program areas and urged CDC to develop standard systems for data collection, analysis and dissemination. Drs. Broome and Koo have addressed the NCVHS in the past about our activities, and in the future more specific updates than mine are planned.
Our current efforts focus on using infectious disease surveillance as a model for developing the National Electronic Disease Surveillance System (NEDSS). CDC has funded 46 states, three cities and five public health partner agencies this year at various levels for NEDSS related activities.
When I started at CDC in 1993, the number of people, outside of the business office, who knew of electronic data interchange was very small and those formally trained in informatics was even less.
Today, people with those skill sets are integral in CDC programs. A training program for Public Health Informatics now exists. The Office of the Director now has an Associate Director for Informatics and a Senior Advisor for Integrated Health Information Systems. Our partners are mirroring these developments.
This background is meant to show that CDC has developed an intense interest in standards at all levels and expresses that interest, in part, through a critical analysis involving our needs and those of our partners. We have participated in all phases of the development of the PMRI report to the Secretary, and Dr. William Yasnoff has been our key representative as part of the support staff.
Given that level of involvement, we find little lacking in the report's broad recommendations. Today you ask us to focus more specifically on -- is of implementation of PMRI standards. Not being a standards development organization, we limit our comments to the draft criteria and proposed PMRI transactions.
CDC reporting systems include requirements for reporting that specifically describe data quality, accountability and integrity, and our programs frequently include information based on analysis of data collected, primarily through the Morbidity and Mortality Weekly Reports.
Hence, we consider these attributes axiomatic in any PMRI system. Without them we would have difficultly doing a trustworthy job of describing and protecting the public's health. We do not anticipate any deviation in our use of the terms accountability and integrity from the way they are used by others. Our use of data quality, however, may deviate from that commonly used.
First, it does not generally refer to the accuracy of data for administrative purposes, though we use these data a in our vital statistics programs. It refers to the clinical accuracy of the data and then extends that description to include other attributes of the event that are described in our various case-definition/description documents.
While public health does not expect more initially from the PMRI than a better case finding tool, we do hope that it will ease our burden in identifying and studying cases of public health importance by providing better, hopefully remote, access to more complete data.
Data operability and Interoperability share in the next level of importance. Public health has awakened and realized that decisions today are expected and needed rapidly. In a bioterrorism event, the requirement might be instantaneous, and for a swimming pool outbreak of Ecoli 0157, it might be days.
Clear, complete electronic communication between providers and public health, and within public health, is now recognized as the most effective way to achieve this goal. Public health has always had a need for rapid communication and we need standards describing mechanical connections that allows for clear communication channels, sent in a secure fashion throughout the system at any time. We view security as integral to a communication system so that we can assure patients of the protection of their very private data. On our end, we will maintain and extend confidentiality systems already in place that allow the security systems to function.
Outbreaks do not stop at geographic borders. We expect our monitoring of these borders to increase in the future and require Interoperability to achieve that goal. In our experience to date, however, we are seeing that the needed Interoperability is difficult to achieve. Our intent is to adhere to industry standards for both transport and format of the message.
Our focus on transport systems is the Internet, but we find a complex mix of similar systems to envelope, address, encrypt, authenticate, and verify the integrity Of the message. We need to work with others to resolve these differences. Our emphasis on format is HL7.
We, like many others, are having difficulty in expressing our clinical needs within the message framework of Version 2 and await the release of Version 3. Like HL7, we are looking towards XML to better express our needs. We do not see an easy solution to the question of message Interoperability without an adequate clinical model that allows us to relate similar concepts.
We are using XML to relate clinical concepts in the HL7 Reference Information Model (RIM) to our developing Public Health Conceptual Data Model with great success. Meanwhile, we are putting systems in place through what are commonly called interface engines to allow us to function in a world of dissimilarity. Given the time it takes to replace legacy systems and realizing that today's systems are tomorrow's legacy systems, we do not see the elimination of these translators.
Data comparability represents our ability to understand what we receive primarily from the private sector. Within public health, we work with our partners to achieve data compatability and, excepting the usual time lag in any consensus process, do not foresee difficulty.
The PMRI report illustrates quite clearly the problems we face in data compatability from the private sector in sections C.1, entitled Interoperability and C.2, Comparability and we would like to mention the following specific points.
CDC needs semantic precision in the data. While we prefer the same term used throughout the system, we require that competing terms describe the same concept precisely. Hence, the ability to relate vocabularies is as important as the vocabulary used. We are looking at various vocabularies, primarily SNOMED and LOINC.
Our world deals with consistently changing scales and norms of measurements, and we need a system that allows the ability to know what scale was used, when and how to interrelate it to others.
Our concepts, expressed in our case definitions, are complex and can change rapidly. Any standard we use must have the flexibility to express new concepts and have the capacity to maintain and extend those that already exist. Therefore, we favor a PMRI system that can meet the changing needs of our case definitions.
Lastly, many of our concepts refer to a group. Clinical vocabularies focus on the individual and, until the concept of the group is better expressed, they will not fully meet our needs. Others in clinical medicine also have the need of the concept of a group, which is not a collection of individuals but an entity unto itself that is based on some shared characteristic. Nursing, for example, has a strong need for this concept. CDC is working with HL7 to include the concept of the group in the developing RIM.
Naturally, in the world of Interoperability we envision above, we expect all this to be done electronically and are focusing on XML to provide the syntax to allow us to express these needs.
CDC is and will continue to be a major payer for our partner's data systems. We are concerned about the implementation cost required to connect these systems to a PMRI. Our current concept is to develop once to common standards and use many times to reduce costs. We would like external interfaces of PMRI systems to allow us to continue to use this approach.
CDC is also concerned about the selection of standards with reasonable implementation costs so that the reporting of public health information does not require burdensome additional expenditures by our partners and data sources. In fact, our expectation is that widespread use of standards and electronic reporting should materially reduce both cost and time required for public health reporting.
The other criteria listed, market acceptance, consistency with other standards, and timely development, we view as having lesser but very real importance. Many of these we see as having more importance in the clinical or private sector.
For the last few moments, I would like to discuss the proposed list of PMRI transactions. CDC presently focuses our highest priorities on the first four: admission/discharge/transfer, laboratory order and diagnostic study information, laboratory and diagnostic study results, and treatment/medication orders.
Of the others, we are finding prescription information to be an interesting case-finding tool and see it becoming more important. Documentation naturally would help in our remote investigation of cases, particularly if it was structured to provide the elements of our case definitions. Several of our programs, such those dealing with tuberculosis, have needs for radiological images. Our developing programs in emergency department monitoring and bioterrorism have needs for vital signs. We now use charge or administrative information to help describe the nation's health and access to health services but view it as surrogate data. We are hoping that more complete access to actual clinical information in the PMRI will make our use of this data unnecessary.
In summary, we have real needs for all of the transactions mentioned, but in reality we are most interested in the subset of these transactions that relate to surveillance data that allows the integration of the PMRI to our case definitions and directly to public health surveillance.
Development of PMRI standards is a complex task. Our needs at CDC illustrate the interrelationship of the various components of the system. Our limited experience shows that all our needs will not be meet by standards. Implementation of the PMRI standards should focus on meeting the needs of most users. Questionnaires and hearings such as this one allow the identification of those standards.
Once key standards are identified, the standard development organizations should be charged with producing them. In the charge to them, they should be told that a standard that will meet most of the users' needs in a timely fashion is required. Testing and refinement of the proposed standard will extend its utility. Once we apply these criteria, CDC believes we will identify a set of existing transactions for the PMRI and these can be implemented rapidly as "low hanging fruit."
Our NEDSS effort has a long-term objective of developing closer integration between public health and the health care systems, which should lead to improved provision of health care as well as public health. Those working on NEDSS see the connection to the PMRI as vital to future success. We thank you for the opportunity to comment on your developing process.
Agenda Item: Review of Testimony
MR. BLAIR: Thank you, Steve.
I think that many of us have questions and let me give the first opportunity for a question to Bill Yasnoff since he was asking about it all the way back, almost three hours ago.
DR. YASNOFF: Unfortunately, Gary Dickinson, I guess, has left.
MR. BLAIR: That's correct. Should we pass it on to whoever else?
And, Simon, I need your help with that.
DR. YASNOFF: I'll pass at the moment.
DR. COHN: Dr. Yasnoff, did you have a comment or a question you wanted to be base for future ---
DR. YASNOFF: Gary's testimony seemed to indicate that there are substantial gaps in the state of standards with respect to security. And, actually, I guess I would like the other panelists to comment on that, particularly Stan Huff, to see if there's agreement on that.
And I'll just say what my questions are and maybe some of the other panelists can chime in. How are these transactions that Gary described being done now, if they're being done at all? And what about similar transaction in other industries? Are these problems unique to healthcare? And if all these standards are needed, who should develop them?
MALE SPEAKER: I had some of the same questions. So when Gary went, I was thinking of my own institution and it's unfortunate Gary's not here. I don't know that we can hold this discussion appropriately without him because I was thinking, I was trying to think in my own institution what this corresponded to and I couldn't mesh them up.
I think in my own institution, for instance, a lot of these things wouldn't have ever been communicated. That is, there's one store for them and the systems access that via remote procedure calls or using LDAP directory services. So there's not a need to communicate that information from machine to machine.
I would have liked to have had Gary here to ask him questions too because I couldn't mesh this up with exactly--- so it seemed to me that he must be working from a slightly different model than what I'm thinking of.
MR. BLAIR: Clem?
DR. MC DONALD: Just further comment. I think you can talk about the security and lack of security standards in two contexts. Perfect, easy-to-use, lightweight security standards we don't have, but if you're willing to, depending upon what your goal is, it's not hard to match HIPAA's security requirements with current technology which is not medically-specified technology whether it's to use certificates or something like secure ID at the remote site plus SSL in communicating the messages.
And then the local host place is responsible for who gets to look at what under the usual security constraints. Those are all doable. It's just that when you talk about a national, everyone can come up to the machine and talk to the machine without knowing who's authentication becomes very difficult.
But I don't think anyone's talking about a national, anybody coming up to the machine and look at anything at the present time. So I think that there are some targets for security that would be very attractive if we could get there, but none of those targets inhibit the immediate kinds of goals that are being discussed for the communication data among people who have the right to see the data and smaller collections of organizations and groups.
DR. COHN: I guess I'll make a comment and then give it over to Jeff. Unfortunately, I don't have any knowledge of the security standard at this point, but I am reminded that they do represent an awful lot of standards that relate to the security piece. Now, some of them are healthcare specific, some of them aren't.
But it does make one wonder that maybe that you've got 90 percent, we need the additional 10 percent of work to make them appropriate for healthcare in the echo we've been seeing with digital signature anyway.
MR. BLAIR: Did you want to comment or ask a question? Yes, it seemed as if I was hearing that there was general agreement with the criteria. I heard from a number of folks like Mary that it fails to properly reflect some of the capabilities of object-oriented processes for communicating information.
And from Steve that there would be more of an emphasis on priorities that, maybe not more, but make sure that we include things that reflect CDC interests in terms of NEDSS and the comments from NDC as well wound up broadening our understanding of things that might relate to retail pharmacy communications.
And I'm saying those things as a preface to my question
which I would like to ask Stan. You notice that in the criteria we had interoperability, comparability, data security, data accountability, and data integrity. Those three which were directly pulled out. Those are the main themes that came out of our PMRI report.
One of the things that I'd like some help from you, Stan, is if those are important, if they have heavy weightings, then it tends to lead us towards things that HL7, for example, is trying to achieve in Version 3. Market acceptance we know from our experience.
The other side of the story is that Version 3 isn't quite available yet and we know from our experience with the financial administrative transactions that fleshing problems out with market acceptance is extremely important for us to go forward and with Version 2 of HL7, it does have market acceptance, but it doesn't have as rich a set of characteristics for interoperability, comparability and quality as we'd like.
Could you give us your thoughts on either how we should reconcile this or a perspective on how we balance this off?
DR. HUFF: What I see happening, that's really part of what you're asking is what I was indicating in terms of implementation guides and what I mean by that is, you're right. If you look at Version @x of the Hl7 standards today, you have, I think it's better than people it is, but it's certainly true that people are using different terminologies, different styles within the optionality that's allowed within the standard.
And what I see is just an incremental change. That is, for instance, we have CDC an implementation guide for immunization. And, in fact, that has very strong semantics. You know exactly the terminology to use and you know what those codes mean.
We can do the same thing in other areas. For instance, for laboratory, we can be much more specific describing the set of LOINC codes that would be allowed and other stylistic things. There's a subgroup working very actively on the representation of microbiology data and that's been a big headache for CDC because the variability of microbiology messages is tremendous. And trying to account for that is, if you're a receiver of all of these different varieties is terrible.
So, the point is that my approach, two things: Version 3 we think is going to be great. It's too early to use Version 3. What we want to do and that's one of the point that I tried to point out, is incremental improvements in existing standards.
I think our starting base is 2.4 with implementation guides and those things will allow the specification of terminology and stylistic variables that will bring that and really make the data comparable and complete and the other things that you talked about.
So I see us doing some -- those things are very doable. It's work, absolutely, but to take from where we're at now and add implementation guides is an incremental improvement that we know how to do. And Version 3 will be that much better.
But if Version 3 is early enough that depending on a time frame of when we think these things are going to happen, we would be much better off to start with implementation guides on Version 2.4 and then avail ourselves of the richness of Version 3 when that is more mature, there are better tools, there's education, people have got it in production systems which is going to take a few years before that happens.
DR. COHN: Can I ask a follow up and then I see Clem and, Jeff, you probably have another comment. This may just be a question that relates to my ignorance, but following along on what Jeff was asking you.
You had spoken a lot about evolutionary change rather than revolutionary and, at least to my understanding, Version 3 is sort of a revolutionary change. Now, am I confused on this one? Is there easy evolution from 2.X HL7 to 3?
DR. HUFF: I think there are steps between it. What I mean by that is, again, there is a real revolutionary part of Version 3 which is starting everything from a normal, formal reference information model attaching vocabulary, a very formal process for development of messages.
And that's where you end up with the very strongest semantics. So that is a revolutionary part, but I think there are evolutionary steps. What I mean by that is, by starting with 2.4 and in an implementation guide adding the strong semantics of a known coded vocabulary so you get strong vocabulary attachment.
And then additionally, there is a proposed standard for the ex-emalification, if you will, for how you can XML V2.4 and so if you tally things up on both sides, if you evolve from 2.4 with an implementation guide that adds strong vocabulary, then add in the XML encoding, now you're only an incremental step from the Version 3 message.
In fact, the thing that's evolutionary about it is the information content is the same. That's the thing that stays constant through all of these things is the fact that the information you need to exchange to meet a business need doesn't change and the fact that you have those things listed and described and that they're attached to the common vocabularies is the part that really, really adds the continuity between V2.4 and 3.0.
There is a break, but I think it's just one more step in an evolutionary stage going from whether it will be --- we're not sure whether 2.4 is the last version of 2 or whether it will be 2.5, but I think going from there to Version 3 is an incremental step and, in fact, one that in demonstrations we've shown that even now the interface engines are easily capable of taking in a 2.4 message and sending out a Version 3 message on the other side.
So I think it's evolutionary in that sense too that software that's commonly available to people will be able to take in a message in one side and actually talk a Version 3 message out the other side. It's that business need and semantics and the implementation guides that will sort of bridge what could have been a large chasm between 2 and 3 to being actually incremental steps between the two.
DR. MC DONALD: Along that line, the first messages that have been created are one-to-one mapping, field-to-field in Version 2 and Version 3. And the power of Version 3 is the ability as one expands into other subject matter, to keep the pieces really lined up and being the same.
As you have more and more subcommittees, it's easier for people to re-invent things that's almost the same, but it's different and working with the model, you end up with this kind of container stuff.
Now you hear the statement made about it doesn't have completeness, comparability, etcetera. I look at those as sort of magical talk. We're talking about solving world hunger, at that level of scope that there's an existence proof here. We don't really know what we're talking about that it's just got to be really, really good.
So I think it's hard to meet that target in real life. I think there will always be this thing will be wherever we are 20 years from now, will be like a millennia short of this perfection. For example, completeness. What the heck is that? Is that where you measured every molecule in my body? As you took a video of me throughout my life so you know exactly what's going on?
I mean no end to completeness and it's in the eye of the beholder. You know, who wants what piece of data. So I think what we really should focus on is a more definable kind of endpoints. Quality, and the big problem is quality is humans being involved in a picture. I can tell you what's going to happen in Version 3 and Version 10.
You're still going to have this field that's called "free text comment" because we can't make it go away. They keep wanting that for these disparate situations. And then when you see they put the whole damn record into that so that none of the structured part is being used.
We have this policing function we're going to have to keep people from being chunkers and lumpers and throwing all that good structured stuff into that last field that doesn't have a tight policeman on i. The truth is our problem with Version 2X messages receiving from five hospitals in Indianapolis is they cheat.
There's nothing in the standard. If they did everything by the standard, we would be in heaven. But they just grossly cheat. They put the units down in the comment field. They have one record that says the result is done. The next record is a note which has all the result in it with the units in normal range.
So those are the kind of things that we just need a tough policemen or something. It's hard to beat. it's hard to fight. I think anyone that's worked with them has seen these same kind of things. So enough.
MR. BLAIR: That's a very helpful perspective. Thank you.
DR. COHN: Jeff, did you have a comment?
MR. BLAIR: I've got about two more, but I want to make sure other folks get their questions in before I.
DR. COHN: Well, Bill Yasnoff I think had his hand up.
DR. YASNOFF: Stan, you mentioned, I think you proposed some steps in the standards adoption process which I'll put words in your mouth, characterized them as tentative or proposed standard providing incentives for the use of the standard, may notice of mandated use and then finally mandated use or some such progression like that.
I wonder if I could press you for some specific times that you think or timetable that you think might work along that line either in general or with a specific example. In other words, how much time do you think each of those stages should take or can you give some examples of what you think might be reasonable?
DR. HUFF: These are totally guesses and I'm always optimistic in these so. What I would think or some of the common data areas, things that we're doing and are in use today like orders, lab orders, radiology orders, lab results, radiology results, medication orders, it would be reasonable to think that we could have implementation guides.
This assumes that we focus on this in some way that maybe we haven't yet, but in actually doing the work, I can see that we can have implementation guides in those areas that could be developed over a year's period of time, something like that. And then that you could have -- again, you would need to select and I think that should actually be guided, which ones we develop should be guided by where we want to implement first.
So, for instance, if our goal following kind of the other part. If our first goal was for after the HIPAA claims attachment, but the next thing after that say would be transmitting infectious data to the CDC, then I think you would, I would guess for a year or two with some leading institutions, etcetera that would implement those, get all of the bugs out and then at that point establish an implementation program that would lead to mandate two or three years after that, some time frame like that.
The overall thing I think is going to take five to six, seven years to evolve. You can do more than one of these things at a time. So you could do many of them in parallel because for a lot of it they're different people that are interested in them.
So you could move it along as separate projects, but I truly think these are not things that we can do in six months or something. I think it's in the 3-5 if we focus on it, we could do it faster. If we don't focus it, it could take 10 years. I'd be interested in other people's views because I'm totally guessing.
DR. COHN: Thank you. I have a question. I see Mike has a hand. First of all, Stan, thank you about your comment about the time frame and you all have to realize I'm an emergency physician. So somehow I don't think like an internist and I certainly don't think like a pathologist in terms of timeframes.
But as I listen to that, I go, yes, that is one timeframe for implementation of things like this. However, and I was listening to Lynn in your testimony from NCPDP where you were observing that some of the things that we had talked about, you were actually really questioning whether they were really PMRI standards or whether they were really some other financial and administrative standard.
I think you had mentioned, for example, the physician/pharmacy interaction that you called "script" as I understand. I think you made the comment that that was really something else like one of these other administrative and financial transactions. Does that require the same timeframe if one were to go forward with that? Is that more ready? Less ready? Is it a PMRI standard or is it something else?
MS. GILBERTSON: SCRIPT is actively being used in the industry today. It has a broad base use, but it is actively being used. It's been around since '96 for available usage. So, it's kind of hard to contain what is all PMRI. The comments from the NCPDP reviewers at the time were more of that is a business function that has patient information involved in it, but it's not, at this point, the actual transmission of patient medical information.
It has to do with because of this specific business requirement to request a new prescription to be dispensed, to request a refill, there might be parts of patient medical information related to that specific occurrence that are required, but not necessarily part of the whole broad picture of medical record. So that was where that question had come up. Did I answer your question at all?
DR. COHN: I was actually going to ask about the time frame also, about the readiness of the standard. Is there an implementation guide?
MS. GILBERTSON: Yes. And it is all ANSI, one of the versions is ANSI-accredited. It's already up to Version 4.1 is going out to membership for ballot. It has been around for quite a few years.
DR. HUFF: Just a question for Lynn. I should know, but I don't. That particular SCRIPT standard, my understanding is that there are lots of coded fields, but most of the coded fields have to do with identification of the patient, unique number for the prescription, etcetera, but that it's not strongly coded in terms of the exact product that would be distributed or the dose or route forms, that it's not strongly coded in the content. Basically, it's a text field where the actual prescript is. Is that accurate or inaccurate?
MS. GILBERTSON: You mean as far as the drug information specifically?
DR. HUFF: In a normal prescription, you have the compound or the tablet that's to be described, the number dispensed and the way it will be labeled. To what extent is that free text within the SCRIPT standard versus very tightly coded and what standard coding schemes are used, if any, in that?
MS. GILBERTSON: From your perspective, it might a little bit different. I'm a techie. So you have to bear with that. From the perspective of the prescriber, there are codes. Now, to the extent of how inclusive those codes are, there's always room for improvement on those.
The standard at this point, has the ability to identify, for example, NDC codes. But recognize the fact that in most prescriber systems, NDCs don't mean anything today. So there's the ability for drug identification field which would be the text name coming from the dastabase that the physician system may be loading in themselves.
DR. HUFF: Right,
MS. GILBERTSON: So, obviously, there is codifying because what drugs they're loading into their systems.
DR. HUFF: Right.
MS. GILBERTSON: And obviously recognizing the fact that the software vendors are highly involved in the SCRIPT growth so that as much as can be codified is brought to the attention of NCPDP. Obviously, once it gets to the pharmacy system, NDCs and all the different databases that they already support are active.
DR. HUFF: Then you can attach those. Part of the thing is that this is a great standard. For instance, my understanding is exactly as she described it. That the drugs that physicians prescribe, there is no standard for that coding set. There are standards for NDC codes. Once you take a pill off the shelf, then you've got an NDC code for what you fill the prescription with.
And so depending on what you want to accomplish again, we couldn't do everything that we want to do I don't think directly from the SCRIPT standard as it stands today. It would need additional vocabulary and additional description, standardized coding sets that maybe the FDA and others could help with to make that truly "standard" and have common semantics for those things, etcetera.
DR. COHN: Mike has his hand up.
DR. FITZMAURICE: I'm going to take an awful lot of credit here. Those are exactly the questions that I was going to ask, but probably not as well. I too picked up, as Simon did, on your testimony, Lynn, that we don't feel that this transaction, the SCRIPT standard that is, should be included in PMRI, but rather recognized as a standard for its business functions.
Yet, you talk about part of it being compliance transactions to notify the prescriber or an event to monitor patients using the prescriptions and others and also, I think, that many of us feel that it's at the point where the physician prescribes a medication whether it's sent to the pharmacy in a hospital or a pharmacy in a local drugstore, that is a key point to remind the physician of other drugs that they patient may be using.
And that would come perhaps from the pharmacy feeding back to the physician, remind of other drug-drug interactions or drug-allergy interactions which has come from the patient record that a lot of this is pulled together. You answered part of my question by saying there's a business part of the transaction and SCRIPT'S may focus on the business part of the transaction.
It seemed to be a larger event however and the discussion with you and Stan on the need for a coding system for what physicians prescribe I think is right on target. I now that VA, FDA, NLM and other are working on developing a drug coding system and a drug vocabulary or at least incorporating another drug vocabulary to try to approach that problem and to get more medical information at the time such a decision is being made.
So I guess I don't have a question. I'm going to move over to Fred. But do you have a comment on anything that I said?
MS. GILBERTSON: You're doing just fine.
DR. FITZMAURICE: I would assume that NCPDP would welcome these code sets as Stan described because it would make that standard more valuable and able to fit not only with the business processing, but with patient safety and the clinical processing of the information as well.
MS. GILBERTSON: Very much. Very much.
DR. FITZMAURICE: In your testimony, I like what you said, there are more gaps that overlaps someone who could measure such a thing. But I tend to believe that. A question I have of you is: Where should it be done? The National Committee on Vital and Health Statistics is a good place to get testimony and public comment. Do you think this is something that should be done by the government, should be done by the public, should be a partnership because we all don't have enough information? Any place you see that being done?
My second question is you talked about the need for storing data in a uniform way so that you can get information over time about a particular patient and can get general knowledge over time about the affects of information, particularly imaging information. Are you proposing that in the patient medical record information standards, it would include the concept of storage standards? That is, how you store the data content so that it's retrievable over time?
DR. BEHLEN: I want to first say that one of the orthodox creeds of standards work is we're not telling you how to do things internally. This is just for purposes of interchange that we're defining these things. So I do want to clarify that when I talk about storage standards, what I'm really talking about is offline ways of storing things, a defined way of packaging the message content into something that doesn't have to have a living computer system in order to read it or at least not a specialized living computer system.
So I think that it was a rather trivial extension to
DICOM to define a way to store offline data. generally speaking, I was promoting that. As far as how to develop these interconnections, I think one of the things that I would point to as an interesting approach and we're getting more and more data as integrating the healthcare enterprise.
It's really just a demonstration project. But it causes, it's able because it's kind of a marketing show. It's a way to attract the commercial resources to actually make vendors participate in it and they do develop a technical framework and a blueprint of getting a bunch of people together for a big connectathon and making things work and showing some proven configurations.
This might be one of the ways to promote this kind of activity. I'm not sure what the role of government would be in that sort of thing, but it is an interesting approach.
MR. BLAIR: Before I say anything else, I just want to say thank you all for rich, informative, insightful testimony. I mean we'll be analyzing and going over your testimony for quite a little bit of time. It was very, very helpful.
One of the things as you many of you kind of read right through the thinking of the criteria for selecting standards and took it to the next step to some degree and wound up saying, "How are we going to weight these? Which ones will either have a higher priority or a higher weighting? While I heard those, I guess I would like to have them maybe explicitly stated so that I could hear them as it flows through all of you. Could I start with Steve?
Which one or two or three are your highest priority?
DR. COHN: We could except Steve isn't here.
MR. BLAIR: Oh, Steve's not here because I think that Steve's ---
DR. COHN: We're down to four.
MR. BLAIR: We're down to four. Okay. Then for the benefit, I remember Steve winding up indicating that data quality and interoperabiilty were high on his list, but let's see.
Fred, I think --- I'm sorry. Mary, I guess, could we go that way? Mary, what are your highest priorities?
MS. KRATZ: I think the highest priority is interoperability.
MR. BLAIR: Okay. Interoperability?
Okay, Fred?
DR. BEHLEN: I was saying data quality.
MR. BLAIR: Data quality. Okay.
Lynn?
MS. GILBERTSON: This is Lynn and I'm still thinking about it. I have to get back to you.
MR. BLAIR: Okay. Who should we skip to? Stan?
DR. HUFF: We're only allowed to say one?
(Laughter.)
MR. BLAIR: No, say what you feel is meaningful.
DR. HUFF: The first thing was, in fact, that basically that the standard had to meet the need that it was targeted for. So what I said is improve the efficiency and effectiveness of healthcare. What I'm really saying there is that if our target is to be able to pass data from our laboratories to the Centers for Disease Control, the first thing is to say, "Does this standard do that? Does the information that we need to pass, get passed?"
The second thing is, again, my second criteria was standards that work, that we only select standards that are implemented and work in a wide variety of production systems. The idea that we would create some new standard and that we would be able to, without implementation, know that that is a good standard or without market acceptance of that, move forward, I think, is fallacious.
We've got to use standards that are already in use, that people know and understand and have been proven to work. The next thing is that they would be cost-effective. That again, ties to market acceptance, but it also says are there public domain tools, are there commercial tools, is there education and training available both technical as well as practical solutions to how you implement the systems?
Then the final couple of things were they need to be sustainable. They need to be ANSI standards, follow open-consensus process, and needs to be a stable organization that's going to support it and evolve it over time and then you need to have, finally, a way to manage change.
And probably my key point in that, again, is really the justification and rationalization for Version 3, that these things are established on a formal reference information model, tied tightly to vocabularies so that you end up ultimately with a strong semantics. It's that information and semantics that passes, that's going to last a lot longer than any particular technology.
XML is the big thing today. I guarantee it's going to be something else five years from now and changing to from vertical bar to XML, from XML to whatever the next generation is, is trivial compared to having an understanding of the business needs and the semantics of the data fields and the terminology that it's coupled to. That's the hard part and that's what you have to have the ability to maintain and support.
MR. BLAIR: Very good point.
Lynn, did you have a chance to think through?
MS. GILBERTSON: Yes. I guess under the categories that are in the report, it's more the data comparability, but it's exactly as Stan finished up with the business cases and the business functions and the common set of vocabularies.
Whether it's translated vocabularies or we all agree that A=A, it really doesn't make any difference, but it's all that work that needs to go into determining what are we trying to measure in this particular business function and what do we have to agree on is the vocabulary in that business function.
So that the foundation is more the importance that we can agree on what it is we're talking about at that level rather than how do we talk it or how do we connect up the things that are going to talk to each other or any of that? And also one other comment just off to the side, Internet is very important part of our lives.
It's very visible, but there are an awful lot of providers out there who are using VISA protocol, using standard message transactions via lease line for M-relays, all those kind of circuitry and network. They're not going away and if the time line is to address this in the near future, that will have to be as much addressed as what could be going forward in the future.
MR. BLAIR: Thank you, Lynn.
DR. COHN: I actually have one question. Then I think we need to break for lunch.
MR. BLAIR: What we might do is -- let's just check with Kepa to see if Kepa has a question.
DR. COHN: Well, let me ask Mary and then we need to finish up here.
Very quickly, you mentioned the GEHR work. Is there anything around there that we should be looking at?
MS. KRATZ: I think that it would be very useful for the Committee to take a look at the Good Electronic Health Record. I did bring a copy with me of the Healthcare Information for Australia, the National Electronic Health Records Task Force in July of 2000 published this report and I understand that this Committee has not had the opportunity to review this.
You might find it very worthwhile. There's a Commission study in there by Dr. Sam Hurd that is extremely insightful and at the very least, I would recommend that you take a brief view of that. Also, the folks at the University College London have several implementations using the GEHR architecture and seeing under and open-source sharing of intellectual properties different business processes being addressed for emergent care, for PDAs where physicians are carrying a component or the cardiac cash lab for pharmacy prescriptions.
All these different business processes collating under a common architecture. It's quite a fascinating process to see and I encourage the Committee to take a look at this report.
DR. COHN: Thank you. I didn't mean to break off.
Kepa, are you there?
DR. ZUBELDIA: Yes.
DR. COHN: Did you have any final questions before we break for lunch?
DR. ZUBELDIA: Is Steve back?
DR. COHN: No, Steve had to leave for the airport.
DR. ZUBELDIA: Well, maybe somebody could address this. Steve mentioned how important it is to have some -- that are not national, but also international standards because we're dealing with other countries. In view of the testifiers that are still there, how important is this? Should we make sure that everything is in synch with international community or should we delegate that to maybe a second phase of implementation of this standard?
MS. KRATZ: I could respond to that. I've done some work with international forums and also through ISO TC215 and I think the task before this Committee is imperative and I see a lot of work happening in Europe, Australia, and Japan and that work on electronic health records using advanced technologies may sesume some of the work that we're doing here in the US.
And I guess it strikes back to my preparation for this discussion in talking to a physician in clinical practice, "Oh, no. The government's going to do something. Is it going to be useful to me when I'm in the clinic, when I need to look at a patient result? Give me something that can actually help me in my practice."
MR. BLAIR: Fred and Stan, can you also answer Kepa's question? I know that both of you are involved internationally with DICOM and HL7?
DR. BEHLEN: I would first like to say, yes, I hope that it will be mandating that it will be an ANSI standard. DICOM is not an ANSI standard. The questions on international standards are partly required when you have -- are specially more important for component markets like imaging which is really an international market and over half of our members have their member vendors have their operations outside the United States.
There are a number of those situations where we do need to be aware of the international requirement for these. I don't know exactly where -- when we talked about the role of DICOM, will we make DICOM and ISO standard? Will we submit that to an ISO standard?
It has been a question that is really a question of whether the benefits are sufficient to overcome basically the effort that's required to do it. We're in decent shape to do it, but it would have to be a significant project which we haven't yet undertaken.
DR. HUFF: I would just say I think it's -- the international aspect is something that's very important, but shouldn't necessarily override other considerations. So it's critically important, number one, because, in fact, there will be lots of situations along the US Canadian border and US Mexico border. All kinds of interactions where the more the international perspective is considered, the better off we will be.
It's also true for market acceptance and other things. In the same way that DICOM has a lot of international business, the acceptance of the standard has to do with vendor acceptance and vendors, in fact, a lot of the US vendors have international clientele as well. And they want to be able to make their systems available internationally.
Everybody is going to be helped, the more consistent we are with international standards. At the same time, I would just say that we want to be able to retina control of our own destiny so that, in fact, we can make progress without necessarily waiting for international bodies to take action.
So I think we want to do everything we can to be consistent, but maintain our own independence and our own freedom to make the right decisions for the US in spite of what might be going on internationally.
DR. COHN: Mary, you want to make a comment. Then Clem and I guess Fred will have the last word before we break.
MS. KRATZ: I just thought of a couple of comments. Tying back to the business processes within the nation and my work with a lot of the academic community, following the doctor global dot com, doing telemedicine with international partners because it's dollar on the barrelhead, fee for service.
This is a business model that exists within the industry today. Another piece is sharing of knowledge especially in the Asian-Pacific realm. I see different academic sites gathering different knowledge basis for disease states that the physicians that we're training today in the country don't have the opportunity to see, but through telemedicine types of applications, they're able to build knowledge basis where they can get experience with unusual diseases and unique datasets.
DR. MC DONALD: Just a couple of thoughts. Firstly, we shouldn't identify international with ISO. I went through a coming of age 10 years ago when ISOSI was the thing. By golly, there was no other truth on earth. This little dumb thing called Internet was just sputtering along. I think we now know how that turned out.
So Internet is the international standard. It is not ISO. ISO is having struggles to a large degree because of its ponderous methods. There's a number of other international organizations including the European computer organization that is doing some of the standardization. So I don't think we should be falling in the trap of saying international ISO. ASTM is international. IEEE is international. HL7 is international. DICOM is international. So I just get that on the table.
The second thing is healthcare is mostly a local event and they can talk about how the patient comes over the Europe and is going to have an emergency, but, by golly, let's take care of the one that's down the street from me first before we worry about that.
They're very, very different because of the economics. There are a lot of very different things. In Japan, all docs are putting their notes in. There is no note longer than five words, maybe ten words on any patient in the system. They see their patients every day.
They'll see them every other day. That's a totally different. They stay in the hospital for two weeks over there. It's cheaper. I don't know how they do it. So there are just some very, very different sorts of processes that we don't want to overstandardize because they won't fit.
The last thing is about the ANSI. This Committee doesn't decide things about how ANSI works, but the law does say that the standard shall be ANSI SDOs unless ---
MR. BLAIR: I think it says you give a preference to it.
DR. MC DONALD: It should be an ANSI SDO unless there is nothing satisfied by doing it. So there is something in law that gives preference to the ANSI approved standards organizations.
MR. BLAIR: I just did want to make one quick remark.
DR. MC DONALD: There is no imaging group though. So you're probably safe.
DR. BEHLEN: One quick note that in the standards work often just a little international awareness goes a long ways that it just avoids our making a dumb mistake of assuming at a base level that any alphabetic character is eight bits or a number of other things.
So often just a little bit of international awareness and staying in touch with what's going on overseas can avoid us making some big mistakes.
DR. ZUBELDIA: Could I make a quick comment on that? The current SDO standards authorized the secretary do not allow international characters in them. I just run into some people from Puerto Rico that were complaining they cannot put any in. That's not international. That's just Puerto Rico.
DR. COHN: Okay.
MR. BLAIR: Could I ask a moment or two here. We had essentially about three hours to go through this first panel and you can see that we ran over a little bit. In the afternoon, if we start at 1:00, we'd have four hours. Do you think it would be okay if we traded off a little bit of time in terms of reconvening at about 1:15 and starting at 1:15, Simon? Do you think we could do that?
DR. COHN: That gives us about an hour.
MR. BLAIR: So that would leave us three and three-quarter hours for the afternoon.
DR. COHN: Okay. So we will come back at 1:15.
MR. BLAIR: Thank you, everyone.
(Lunch break)
DR. COHN: This is to start the afternoon panel. I see that we don't have everyone here. Actually, we only have two of the five. I guess we heard that Jim Cimino may be a little late getting in. Obviously, we'll catch him when he arrives, but why don't we give our two panelists introduce themselves and then we'll get started.
My name is Robert Selliger. I'm President and CEO of Sentillion. Sentillion is a relatively new company that manufactures integration technology for the healthcare industry. However, relevant to today's session, I'd also like to point out that I'm currently the Co-chair of HL7's CCal technical committee.
CCal publishes a standard for context management which I'll elaborate on a few moments. I'm also former Co-chair of the Andover working group and also former Co-chair of Hl7's special interest group on object brokering technologies.
With 20 years of healthcare industry experience, I bring hopefully to the table a preview as both an architect, a technologist, an entrepreneur and a businessman.
DR. COHN: And our testifier's here.
MR. RUBIN: Yes. This is Ken Rubin. I'm representing EDS today. I've been supporting the Veterans' Health Administration IT architecture for a couple of years now with my primary health care experience. I'm serving as their representative to HL7 and object management group. But I'll be representing EDS in the testimony today.
DR. COHN: Chris?
DR. CHUTE: Yes. Chris Chute. I'm professor and head of medical informatics at Mayo Clinic, an internist epidemiologist by training, vice-chair of the ANSI health information standards board and I'm interim convener of the ISO terminology work group.
MR. BLAIR: The only comments that I would add before we get started is, our focus is on --- Can you hear us, Kepa?
DR. ZUBELDIA: I can hear you fine.
MR. BLAIR: Okay. Our focus is on your crtiquing our process and our criteria and our draft questionnaire for selecting PRMI standards. We've gone through a number of steps to try to see how we go about this process. It's clear that the answers are not obvious as to the best way to do this and so we have, in effect, a straw person in front of you in that framework document and although you may want to give us a little bit of background in terms of how your experience or observations about the industry might reflect on these standards, our primary interest is on your critique of our criteria questionnaire scope. And we do want to really stay on time. There are going to be some other folks that are going to join us. So, please try to focus your comments within a 15-minute session and then we'll have questions after.
DR. COHN: I think we have two others that need to introduce themselves.
MR. SAFADI: Yasser.
MR. BLAIR: Yasser al Safadi?
MR. SAFADI: Yes. I'm Yasser al Safadi from Phillips research.
MR. BLAIR: And?
DR. ROZEN: Michael Rozen from WellMed.
MR. BLAIR: I think we're being this time only because the alphabetical list went the other direction here.
Agenda Item: Vendors/Providers
DR. CHUTE: Today, I'm deviating slightly from the recommended format as I'm prone to do. I'm first of all want to give kudos both for this report that was sent in July and also for the new criteria. I will make explicit comments on the criteria though not necessarily consistent with the outline that you had previously and then I want to emphasize three points. Those being a re-emphasis on understanding barriers to access to these existing standards and proposed standards, a plea for computable algorithmic formats, and think a recognition of the importance of interstandard comparability in the context of shared models.
If nobody else has said it, I'm sure they have, but let me repeat, I found the July 2000 report to the secretary to be an outstanding synthesis of the current status of the field and as a document contain strategic, prudent, and responsible recommendations. Similarly, the recent criteria that you've drafted is a welcome beginning as a template for this kind of issue.
Specific comments on those criteria. As an information gathering instrument, I believe that it probably has appropriate depth, breadth, and detail and that it is highly desirable to derive from such an instrument templateable or consistent or comparable information about the standards that are being considered.
However, I do have two concerns. One of them focusing on consistency. If you accept a premise, and you may or may not, that an UBI criteria for clinical information interchange is that it be comparable and that it be consistently created, clearly the comparability is incorporated rather well in the criteria that is being described.
However, data consistency, per se, does not seem to have the same level of emphasis. You do talk about consistency across standards within your recommendation Number 5, but that's not the same as interoperability and let me give you an example of what I mean by this notion of consistency.
If you take any arbitrary constant element in this context, congestive heart failure, and the question is: In a clinical recording message inference recognition, bill whatever. Is that concept characterized consistently across providers and across systems and across environments?
You can begin to look at questions like: What is the context of that description within a record? Would a reimbursement formulation of the concept differ significantly from a quality oversight formulation of the same notion? Is there a distinction between a trigger point, say, for a guideline versus a final diagnosis and how do you operate along that spectrum in terms of consistently representing patient description?
And then, finally, are the criteria for assignment of a given element consistent internally? Do they depend upon variable and vagrant human judgment? Is there variance in the context of a sub type and detail associated with, in this example, congestive heart failure?
Do we talk about ejection fractions? Do we talk about other elements of detail that would further characterize it? And you could, frankly, plug in any clinical example and come, I think, to the same kind of conclusions.
It's important to recognize that this notion of consistency is not restricted to content standards. That is to say, I'm not picking exclusively on vocabularies, terminologies, and classifications. One can make the same assertion and I think the folks at HL7 have, on message specification, information models, cross standard meda-data such as XLM mark-up ensuring that a consistency between and across them is an important criteria.
The next major comment I have or concern about the criteria as specified is more philosophical. Is the goal merely to inquire among standards developers or is there any desirability in asserting guidance or, if you will, desirable criteria, desiderata as Jim would be inclined to say?
So, clearly the notion of inquiring with a standards developers is useful and necessary. It raises, incidentally, structure format issues of how that information would be managed or manipulated and let me shamelessly put in a plug for the question of the US Health Information Knowledge Base.
But the political question I assert more specifically is whether or not these criteria for standards selection should begin to incorporate prescriptive information. That is to say, should or perhaps shall standards adopt principles, to paraphrase your categories, interoperability, comparability, acceptance, consistency, affordability and so on.
Is that a desideratum or are they desirtarata or is it merely an information gathering exercise. Now, let me proceed to the three major points that I wanted to emphasize which are barriers to access, computable formats, and interstandard infrastructures.
In the context of barriers to access, as you know, as we all know, standards are slow, expensive, difficult, and painful. That's putting it mildly. The question is: How can we really minimize the barriers to adopting standards? And I would assert that even the potential for an exploitive cost basis for mandated standards add, to paraphrase, insult to injury and that we should encourage in the context of these criteria, public and/or government underwriting of these standards development.
Or alternatively, if that proves to be economically unfeasible, dare we raise the question of regulatory arenas so that standard specification do not de facto create monopoly environments that could generate exploitive pricing consequences in the US health system which would further dampen the progressive and presumably public health good of wide-scale adaptation of underlying standards.
So that affordable or publicly available standards should be preferred and once identified as a PMRI standard, what are the issues associated with pricing restrictions within specified ranges and the concern or dare I use the regulation word, the notion that revenue should not be reprogrammed away from the development and maintenance of the underlying standard to other secondary purposes of the developing organization.
The second point I want to focus on is this notion of computable formats and support, most principally in the domain of content standards. The assertion is that patient records standards should be fully specified and implementable and, by that, we mean at a computer data level, that it should have implicit within its content executable logic systems that should contain internal rule sets and computable criteria that would obviate the necessity, not the possibility, but the necessity of human judgment at every stage of the standards data element entry, interpretation, mapping, and recognition.
Let me give you an example. In the context of pick one, ICD9 or ICD10 clinical modification, arguably they embody very elaborate, elegant, and comprehensive rule systems. However, I would assert that those rule systems are specified for human interpretation manifest through typography, indentation, index entries, instructions such as code as, code also, include, exclude, in a non-computably precise fashion.
They are not sufficiently specified so that we could execute logic rules against them and I'm simply making a plea that to the extent practical, public medical record or patient medical record standards should have internal consistency and logic rules associated with them.
Finally, the third and last element is the notion of interstandard infrastructure. This is not a new problem. This is not something that has gone unrecognized. The historic dialectic, if you will, has been between data content models and information models. The terminology or the reference information model if you will. To borrow Angela Rogemorris' overworked example, does family history belong in a box in a medical record environment that you fill with diagnoses or is it a terminologic characteristic where you modify a given diagnosis with the moniker of family history?
That is a trivial example, but highlights the notion of cross standard interoperability and consistency. Stan actually suggested at a meeting that I was at a week or two ago, the notion of a shallow information model. Again, not a new idea associated with templates and/or mark-up syntax.
You could turn this into an XML discussion if you wish. They are purely interoperable, but the hope is that in a shallow model environment, one could have a corps clinical concept described and then associated with it in a consistent templated way notions of severity, notions of anatomy, notions of pernicity and that those notions can be intelligently inherited by domain-specific consideration.
Consider the cancer example where clearly one might want to augment or modify to accommodate cell type, various types of formal staging criteria be it TNM or the American Joint Commission on Cancer, and notions of laterality.
So this would imply the notion of a cross standard metadata. I assert that one of the first steps is to compile the existing metadata about standards. USHIKB, the US Health Information Knowledge Base again comes to mind to entertain an environment, entity, organization or form that would enable SDOs to re-liaison among themselves in shared information models and/or XML mark-up standards which are, again, to some extent interoperable with the intention that consensus and compliance be the goal, that the selection criteria for implementation be a willingness to play on the part of those SDOs in these interstandard consensus environments.
So, in conclusion, I think there has been an excellent description and first steps towards these criteria. I hope that we can promote discussion about the issue of guidance and prescription as opposed to mere data collection and recommended criteria that we can actively discourage barriers to standards access and encourage computable formats for data content and engender interstandard agreements for interoperability and consistency.
Thank you.
MR. BLAIR: Thank you, Chris. Do we have a copy of your testimony?
DR. CHUTE: You have a copy of my little slides on paper and I will cheerfully submit it electronically to whomever.
MR. BLAIR: Okay. Jim?
DR. CIMINO: Yes.
MR. BLAIR: Could you introduce yourself and we'd like to hear your testimony. Could you try to keep it within 15 minutes and focus on critiquing the criteria, the questionnaire, and the scope?
DR. CIMINO: Okay. It's not going to take me long to say what I have to say.
I do have a handout. Unfortunately, we had a major copier failure this morning. So I don't have copies of it, but we can work that out I'm sure.
My name is Jim Cimino. I'm an associate professor of medicine and medical informatics at Columbia University. I'm actually here wearing two hats I suppose. One is, as a member of the team that's developed the clinical information system at New York Presbyterian Hospital where I am not a creator of messages, but I'm a receiver of messages and a user of messages and, therefore, have some interest in seeing some good standards developed.
I'm also Co-chair of the vocabulary technical committee of HL7. I'm not here to promote HL7, but I've learned a lot about messages since I've been involved with HL7 and so that has given me a little bit of perspective. I'm not sure what the big picture was since I was only seeing the little piece while I was there and often felt that there was not a lot of attention paid to the notion that what we're actually talking about here is taking care of sick people. I was very pleased to see that that's a central feature of the document.
MR. BLAIR: Kepa, are you able to hear Jim? Kepa, are you there? Kepa, are you able to hear Jim Cimino?
DR. ZUBELDIA: Yes.
DR. CIMINO: That said, I actually do have some fairly specific slides looking to respond specifically to the query that was posed to me. So this won't take very long I don't think.
The first question was selection of criteria for message standards and the first thing I wanted to say is to look at the notion of loss of information in the message and are the data that are being captured and put into the message being dumbed down, if you will, to facilitate the transfer or is the original meaning of the data being maintained? I think that's going to be crucial for sharing information across systems.
Second is, and this is one near and dear to my heart, and what Chris is talking about as well is, does it employ high-quality terminologies. That is, the message is only as good as the content and if the data in the message are not captured in high-quality terminology, the usefulness will suffer.
Third is, how can the government support the standard whether it's through financial support or other resources to help the creation of standard. I've been very impressed with the diligence of the HL7 volunteers in creating their standard and that's a tremendous amount of work, requires a tremendous level of effort. Frankly, I don't know how these people keep their own jobs given the level of effort they have to put in. So, there's certainly a need for real resources to get this work done.
There are general questions for the standards development organizations. First of all, what is the level of active participation of all the interested parties? That is, not obviously -- the ANSI requires that there is active participation as possible. But the real question is how many people participating? So, for example, people like me who have another job and have to go to HL7 and try to participate, it's very hard for us to do so.
So it's a good question. For instance, our medical informaticians, for instance, are involved in this were active. Are we active participants because of just the practicality of our being able to participate. So that's one question to look at.
The second is: What evaluations are being done to look at how well the -- standard is meeting the needs of all of the interested parties. Then there are the questions themselves in your questionnaire. And on data quality, first of all, major consideration is when it will alleviate the duplication of data capture?
I think you refer to that in your document, but I think that's an important thing to note. That is, the data being captured for a primary purpose and then being reused or do we have to recapture the data every time we want to fill in something in a message. So that's one piece.
The second is: Is there a data model that considers all the users and all of their needs? So, a data model for instance that HL7 has is the reference information model. Just a little piece of it and central to it is the patient which is nice to see. There are a number of different attributes which I won't go through and the patient links to a number of different entities in the diagram.
This is the entire Hl7 reference information model which I won't through right now, but certainly it's available, but the notion here is the complexity that's here. This is a lot of work and this input from lots of different folks. From vendors, from users at all different levels. So there's a lot of work to be done to create these standards and I think it's important to look at messaging standards and look at that reference information model to make sure that it's sound.
And then the third question on data quality is what are the criteria used for selecting the terminologies and, for example, again referencing HL7, HL7 has a number of criteria which, again, I won't go through. They'll be in my handout, but the point is to have some criteria not to simply say, "Okay. We have a field in a message. We need a terminology. Here's a terminology. Let's use that." There actually are criteria for saying, "Is this terminology going to meet the needs of this particular field and this particular message?" And that can be evaluated.
And then, finally, transactions and there are two transactions that I would be interested in and did not see in the list although maybe it's disguised in some other form. The first is alerts and reminders. So messages about telling a patient that they need to have vaccination, telling a physician that there's a problem with the drug they ordered. But I didn't see that covered in the messages anywhere.
And along with that goes the logic and guidelines that would be used to generate those alerts and reminders. And so, putting those in a message will allow us to share them across institutions. So that's really my main comments and two additional comments.
One is, should there be now -- you're looking at standards for messages -- should there be standards for terminology as well? And something to consider if you're going to require --
MR. BLAIR: That will be probably our next phase or third phase, yes.
DR. CIMINO: Okay. The last is wind up saying keep your eye on the donut, not on the hole. I think you're doing that very well, but I just want to put in my two cents that we're here about patient care and everything else will flow form that. And, again, I congratulate you on the work you've been doing so far.
MR. BLAIR: Thank you, Jim.
And, Simon, you could help me maybe? Ken Rubin?
DR. COHN: Michael Rozen?
DR. ROZEN: Thank you. I'm Michael Rozen from WellMed. We are one of the e-health companies.
Mr. Chairman and ladies and gentlemen of the National Committee on Health and Vital Statistics and guests. It is with humility that I accept your invitation and probably with even more humility now because I don't think I'm gong to be quite as kind to the NPRM, and present my comments on a Draft Framework for the first, phase in the selection of Patient Medical Information Standards for recommendation to the Secretary of Health and Human Services.
While this draft framework focuses on the selection of message format standards for the PMRI, I feel I must start my comments at a higher level. Inscribed on the National Archives building in Washington is the quote: "The Past is Prologue." When I was a medical student, I remember one afternoon spent in the historical section of the medical school library reading about the indiscriminate use of leaches.
They were very popular prior to the 1900's and books abound with information about the various leaches, how often to apply them, in what pattern, for how long, how many, etcetera. Indeed standards existed for their use, but nowhere did anyone really stop and document their value. At the highest level, the question begged, "Were they of any value?" Today we know they do have benefit in re-implantation surgery.
The electronic medical record has been in existence for approximately forty years and I can trace much of its history through my practice of medicine. Adoption has always lagged behind potential and technology has frequently been the reason provided for its failure. In 1974 when I entered private practice, we computerized much of our internal transactional activities.
We did not have cost effective communication capabilities for ubiquitous comectivity that exist today. Medical records existed as flat files in whatever location the patient went. When information needed to be shared, a copy was frequently sent with the patient.
In the 1980's, we continued to upgrade our computer capabilities and incorporated fax as a standard mode of interaction. In the late 80's, I became active in leading efforts to develop Community Health Information Networks. In Southwest Ohio and the State of Ohio, which was one of the original Hartford Foundation Grant sites, we explored technical and political realities of medical information sharing. Important to this effort was the adoption of an electronic medical record.
This record was healthcare system centric and did not provide for patient input. Implementation was difficult because most health information did not exist in electronic format and interpretation of the data required thick application interface programs. Thin browser technology had not yet occurred.
Also we were reminded of the political reality of the healthcare industry - that stakeholders are unwilling to give up control of their information. They are willing with proper authorization and authentication safeguards to share access to information, which remains under their control. If a single record were created, who own it and who would maintain it? How would it follow the person through their life? During our work with Community Health Information Networks we were able to make more progress when we focused on "rights" rather then "ownership" of the information.
Who had a right to access that information?. How was that right obtained? How was that right executed or conveyed?
We learned in the early 90's that healthcare stakeholders did not want to keep their information in a single databases or locations. The distributed nature of healthcare data and the need to access it from multiple locations meant we needed stakeholders to store the data in a format that would provide access at time of need to those with proper credentials. The advent of browser technology provided a cost effective solution.
In 1996 1 started an Internet Company dedicated to creating an electronic consumer/patient personal health record that would provide people with a place to store and access their health information. Initially, the information was self-reported.
Recognizing the need for an integrated suite of personal health improvement programs including health risk analysis and energizing the patients self reported data, I merged our company with WellMed in Portland, Oregon.
Today we witness the evolution of e-health, a consumer centric Internet experience, which takes advantage of the four driving characteristics of the Internet: thin browser interfaces, ubiquitous connectivity, data empowerment and interactivity. This e-health revolution, composed of non-traditional healthcare stakeholders initially, that is, consumers, has now been joined by traditional healthcare stakeholders who are moving to deliver e-care, using the above driving characteristics for patient treatment plans and management of chronic illness.
PMRI needs to be able to enhance remote monitoring and facilitate patient management of their chronic illnesses. Both the Robert Wood Johnson Foundation and the Committee on Quality of Healthcare Information presents statistics and numbers supporting that contention.
ASTM workgroup E31.26 is working on Standards for Personal Consumer Health Record, a lifetime record of the patient or consumer's health. E31.26 defines the Personal or Consumer Health Record as "an electronic application where individuals can maintain and manage their health information and that of others for whom they are authorized in a private, secure, confidential environment that allows the individual or other authorized persons to access and share such information."
The ability of the PMRI to provide continuous connectivity and reach out to access information is emphasized in the Stephens report that, again, talks about adding value by having information be ubiquitously connected.
Therefore, at the highest level, I am concerned that the proposed Patient Medical Record Information Standard focuses on an old paradigm of medicine that is healthcare centric, not patient-centric; that fails to incorporate the advances in communication technology and thin browser interfaces; and is mired in a vision that failed to capture adoption twenty years ago.
If I have not impugned all my credibility so far, I would like to go on and talk a little bit about WellMed as an example of what is going on in the e-health community and what we are doing and why I think it bears upon my presentation before this.
My current role is Chief Privacy Officer for WellMed. To provide you an insight into what the e-health community has been doing and how the face of medicine has changed, I will present a few slides showing a little of the functionality of our company.
We have a unique and forward-thinking approach we think that effectively blends patient self-reported data with professionally sourced data using data interchange, thereby hopefully raising the respect of self-reported information and giving consumers or patients greater equity in the healthcare process through access and control of information.
We see the healthcare universe as being patient-centric and use the Internet as a channel for that communication. Our programs are based on a platform that combines patient self-reported information with professionally sourced information; indexes content based accepted referenced terminologies and then applies business rules to create a personalized health management experience.
Our personal health manager helps people assess, record, improve and manage their health and health information. And the way we do this is by trying to energize this information in pulling it together. The key sitting behind us is to have effective data interchange that allows us to take the patient's self-reported information and combine it with professionally sourced information, to index that information using accepted reference terminology sets and then index content and supply content to that individual in the hopes that wherever they're at in Peceska's(?) change curve to influence their behavior.
This is very important especially as you look upon remote sensing and other capabilities that we now have available in managing chronic illness.
Communication is at the core of our functionality.
Another way to look at our platforms and desired functionality is demonstrated by the next drawing in your handout. What it shows is an assessment platform and then a health record platform, a care management platform, a messaging platform and, finally, a personalization platform. And all these function together as what we call a Health Communication Platform.
So how does this relate to the proposed standards? As a general comment, I feel that there is no recognition of the need for information to be accessible. Information needs to be accessible, I feel, on a 7X24 basis. I think also the Committee needs to consider how to weight the standards -- which of these standards are most necessary.
I feel it would be helpful if demonstration projects could be encouraged with the sole purpose of trying to understand which of these implementations and which of these standards will truly add value to the stakeholder, the patient.
Specifically in Section 1, Draft Criteria for Selection of PMRI Message Format Standards. Does this adequately address the need for information to be posted by healthcare stakeholders for access by others who have proper authentication and authorization? Does it provide a mechanism for secure patient communication with healthcare system stakeholders including physicians in a distributed patient environment?
Under Section 2 of the Draft Questionnaire. Under VIII, I would recommend under Indicators of interoperability, adding, "Is the standard capable with thin browser interfaces?"
Under Section IX, Indicators of Data Comparability, I would add a Section G, "Identify usability testing for implementing this standard."
I would also recommend two other areas be included: Item X, Education and Training. Can the standard organization provide documentation of education and on going training required by users to maintain efficient implementation of this standard.
So often in healthcare, in my observations, once a system has been implemented, it's impossible to keep it running because of a lack of ongoing training and programs available to those that are entrusted to use that system.
In XI, Facilitate Communication. I already mentioned having the data available 7x24. I think we need authentication standards. I think we need standards looking for documenting access authorization. And, finally, mechanisms for providing access in distributed healthcare environment.
Under Section 3, proposed list of PMRI transactions to be considered for HIPAA standardization recommendations. Most health information resides with patients and their families. While initial focus is on transaction standards, current and evolving clinical processes need to be recognized so that systems being implemented are able to take advantage of these changes.
So I would recommend:
11 - patient personal health information from Personal Health Records including health risk analysis and interests and behavioral characteristics and trends of the patient;
12 - mechanisms for integrating information from remote monitoring of parameters for managing chronic illnesses;
13 - within the record, there needs to be a big focus on communication between patient and physician.
Under Section 4, I would recommend adding the two following:
5 - are there additional functions, e.g. communication, for which standards have not yet evolved but other criteria for use exist;
6 - what standards will be adopted to facilitate posting and remote accessing of information on a hospitals website?;
7 - do these standards permit variation in who is the keeper of the PMRI? Does functionality change when the keeper changes?;
8 - how does authentication occur in the absence of a single unique personal identifier?
In summary, I offer the following suggestions to facilitate criteria for selection election of PMRI standards:
1. Prior to finalization of the Standards Selection Criteria, I would encourage a review of the definition of the PMRI.
I've listed five points that I think are important in that review:
2. Timely communication is core to PMRI functionality. The PMRI is not a flat file and should not be considered as such. I have offered three areas of concern.
In Section 3, specific to the criteria for Standards Selection presented in your report to the Secretary, I would recommend weighting of the selection criteria to facilitate selection based on compliance with standards and (b)more attention needs to be focused on emerging technologies that facilitate real time posting of data and interaction.
To use a metaphor, the PMRI should not be an elephant that is big, heavy and slow moving, but rather a Cheetah that is sleek agile fast and able to reach out quickly for what it needs.
Thank you.
MR. BLAIR: Thank you, Michael.
MR. RUBIN: Mr. Chairman, members of the Committee, honored guests. It is my pleasure to be with you today representing EDS in this testimony to the National Committee on Vital and Health Statistics regarding the Draft Criteria for selection of PRMI standards.
My primary healthcare experience has been with the Veterans Health Administration (VHA) Enterprise Architecture Office, where I serve as their Application Architect and representative to the Object Management Group and HL7's standards organizations. In addition, I have been a part of the reference modeling activities under the Government Computer-based Patient Record (GCPR) Project.
EDS is a large-scale systems integrator that leverages standards, technologies, and products to deliver integrated solutions that add value for our clients. This testimony will center on that perspective, providing a view from the community intending to apply PMRI standards, and their
impacts both to healthcare information systems and to the tools with which those systems are built.
PMRI standards will offer healthcare organizations and integrators the opportunity to purchase, integrate, and develop systems that minimize risks associated with single-vendor, single-product solutions. I see PMRI affecting several business lines (clinical, administrative, research, etc) by providing consistent, meaningful data of quality and integrity.
I commend the committee on the PMRI initiative and encourage you to remain steadfast in recognizing that there will never be consensus on technology, platform, product, or business practices. Initiatives such as open interface specification provide the loose-coupling that is needed to allow disparate organizations to continue to mteroperate while doing business autonomously.
As you proceed, it is important to recognize that integration challenges do not end at organizational boundaries, but extend within organizations as well. This work can significantly benefit healthcare institutions in addressing internal interoperabihty issues as well as enabling interchange across organizations.
In its consideration of standards, I encourage the committee to recognize the issues that extend beyond our national boundaries. Be it to support a multilingual environment, epidemiological interests that cross borders, corporations with a global presence, co-operation in a multinational peacekeeping force, or simply citizens traveling abroad, PMRI must be positioned to support interchange needs that are affected by non-US parties.
For maximum PMRI utility, organizations must be capable of extending the standard to address these "external" interests without sacrificing the fundamental interoperabifity offered by PMRI interchange.
Though much attention is being paid to "customization," this capability must be differentiated from "extensibility." In my view, sacrificing the core standard to bend to local interests or
optionality the expense of interoperability is "custormization." Conversely, the addition of information to support interests beyond the scope of the core standard would be extensibility. Without an extensibility mechanism, organizations are shackled to a standard and often forced to misuse its constructs, encouraging localities to bend the rules. An extensibility mechanism benefits the longterm utility of PMRI.
I urge the Committee to broaden its view of integration technologies to extend beyond message-based integration and include alternatives such as middleware solutions. Though messages and message-based technologies have a clear value and several advantages to information interchange, they are not the only technology capable of doing so. The SDO Questionnaire may benefit from being broadened to allow NCVHS to consider other alternatives.
Acknowledging a separation of concerns between the care of the Patient Medical Record and the transport of that record is of tantamount importance. Without separating these concerns, the PMRI will not be able to take advantage of evolving and maturing technology solutions.
I have some directed comments. In Section 1,the Draft Criteria, in my view, the criteria identified are well suited for selecting the PMRI standards. I feel strongly, however, that use of weighted criteria to place emphasis on those areas that are particularly important would add significant value.
My recommendation is to place a heightened importance on interoperabflity, data comparability as defined in your July 6 Report, flexibility, and relationship to other standards.
I propose altering one of these criteria. The current criterion--consistency with other standards--implies that there must be alignment across relevant standards activity. In practice I feel this is both undesirable and unrealistic. Each standards organization brings a differing perspective and thus a different value.
Instead, if the emphasis is on the relationships among standards, the emphasis shifts from alignment to synergy, where the touch-points between standards can be explored and understood, allowing each standard to be used to its advantage. This is a stronger value proposition to the industry than uniformity.
"Market acceptance" is an important criterion so long as it is viewed in the context of a changing landscape. Standards and technologies wax and wane. Technologies that are emerging should not be discounted solely because of minimal healthcare penetration, particularly if they show strength in solving similar issues for other market sectors. Conversely, standards with significant market share should not be blindly embraced at the risk of prolonging a potentially aging standard.
With regard to data quality and accountability, there is a need to transmit relevant metadata in conjunction with the data itself. For instance, this metadata will provide insight into the steward and source system of the transmitted information, and facilitates a shared meaning and understanding.
Comments on the questionnaire. As is, the SDO questionnaire provides a strong basis for understanding much of what the SDOs have to offer to the PMRI initiative. There are a few objectives identified in the Uniform Data Standards report that may not be addressed by responses to the questionnaire as it stands.
The following suggestions are intended to provide insight as to how SDO's and their standards can address some of the specific objectives from the report.
Interoperability Categories. The report introduces three categories of interoperability: basic, functional, and semantic. The SDO Questionnaire, however, does not expressly differentiate among these categories. Instead, the interoperability level is left to inference based upon items such as the relationship between terminology and message structure.
Categorization Vehicle. In my experience, I have found that some objective measure, such as a categorization matrix, assists in differentiating standards and relevant touch-points between them. I would urge the committee to identify or define some objective metric to serve this role. Existing public work such as the viewpoints from the ISO Reference Model for Open Distributed Processing or RMODP may provide good seed material for such an effort. In doing so, I believe that NCVHS can provide a great service to the industry-government, private, and standards groups alike.
Cost Metrics. Though completion of the questionnaire would provide some value in understanding the costs incurred to purchase a standard, it would not sufficiently identify the reasonable expected costs to use the standard. The cost of implementing standards within organizations extends well beyond licensing of the standard itself. In fact, initial integration costs, off-the-shelf product costs, development costs, and recurring maintenance (such as keeping current with the evolution of the standard) are likely to be the costs of primary interest.
I recommend soliciting from SDO's some notional cost model for organizations of a predetermined, specified size with respect to organizational experience with the standard. For instance, one model might include expected costs for an inpatient hospital with 200 beds using HL7 2.x to upgrade to HL7 version 3.0, with relevant assumptions being documented. This figure should be provided both for initial development and integration as well as for subsequent maintenance stages.
Comments on Subsections VII and VIII. I felt that the questionnaire would benefit by expanding the scope of questions in Subsection VII, discussing timely standards development, and Subsection VIII,which is addressing flexibility concerns.
Some questions for consideration with respect to timeliness. Historically, what has been the average time for general availability of commercial tools to support a standard after its adoption? What about conformance tools? What relationships exist, if any, to expedite promulgation of your standards through other Standards Organizations? That goes back to the point I believe Mary Kratz made this morning about relationships across standards groups and penetration in multiple standards giving better marketshare. Subsection VIII,how are new terms and new codesets supported within the standard and are changes required to the standard or deployed systems? What extensibility mechanisms are offered to allow for the inclusion of new terminologies? What relationships or dependencies exist between the standard and lower-level transfer protocols? How are extensions beyond the scope of the standards supported?
Comments on Section 3, the Proposed List of PMRI Transactions. As I am primarily representing a technical community, I will defer comments in this area to the relevant clinical community. While addressing PMRI with colleagues, however, some concern was expressed that identified transaction set did not appear to address the JCAHO ambulatory care requirements, n particular, "a summary fist of all significant diagnoses, procedures, drug allergies and meds.
Section 4, Additional Comments or Critiques. Based on my experience, I believe the following areas are worthy of consideration for inclusion in the PMRI identification and selection process:
Separation of Concerns. When considering the interoperability of patient medical record information, it is important to recognize that two concerns are being addressed. The first of these concerns is the content itself: identifying the information that is of interest, and appropriate authoritative sources for describing that information. The second concern is more technically oriented, addressing the means by which that content is transferred.
While messaging and message set identification is a proven, effective vehicle for interchanging information, several alternatives such as middleware, service-based architectures, and so forth, may be as well or better suited to address these needs.
My concern is that given the current framework for SDO responses and the apparent emphasis of the questions, these alternatives may be deemed out-of-scope though they merit consideration. I would urge the Committee to broaden the questionnaire to ensure that these alternatives can be considered.
Vehicle for Comparison of Standards. As previously mentioned, I believe that the NCVHS is in a pivotal position to identify an objective framework that can be used industrywide to compare and understand standards. I would not view such a tool as a measure of quality, completeness, or judgement of the standards themselves, instead serving as a roadmap for the 'industry to illustrate how the standards fit together.
For instance, this could be instrumental in identifying the touchpoints between technologies, message formats, and miiddleware and, as such, provide guidance both to understand the landscape of standards and to leverage each to its strengths.
Open Registration Authority. Given the importance of allowing organizations the flexibility to carry out their business practices within the general framework of the PMRI standards, a public forum is necessary to allow for the open registration of these extensions. This forum would allow localities and organizations to relate their extensions to the core standard and to define relationships to other extensions.
This activity would likely be a natural extension of the ANSI HISB Metadata Registry work. There is precedence for this activity both within and outside of healthcare, with initiatives such as Residant and the Good Electronic Health Record or (GEAR) Archetypes. Regardless of the forum, it is essential that the PMRI standard allow for interchange at the semantic (or knowledge) level while still affording organizations the freedom to build on that standard to address their local or specific needs.
If the core standard is not capable of addressing these concerns, organizations will be faced with implementing multiple standards or relying on a semi-standard, semi-proprietary solution approach that ultimately has an impact on interoperability.
In closing, I would like to thank the Committee for the opportunity to present my views in this area. Although ultimately this testimony reflects my views, it also reflects input from several individuals who were kind enough to offer me their thoughts, comments, and support. In particular I would Like to recognize Tom Beale, Jim Demetriades, Doug Felton, David VonRinteln, Steve Wagner, and Sherri Walter for their substantial contribution to this work.
Respectfully Submitted, Ken Rubin.
MR. BLAIR: Robert Seliger.
MR. SELIGER: Robert Seliger. Correct. Good afternoon.
MR. BLAIR: Let me just mention if I may, okay, because I think we failed to communicate clearly just so you'd know that the framework that you're looking at now was intended to address only message format standards as the first phase in the process of selecting PMRI standards. Later phases might include medical terminologies, data content, maybe an additional wave of message format standards as some form of communication. I just wanted to put that in perspective. I think that that might be helpful. Go ahead, Mr. Seliger.
MR. SELIGER: When I was asked last week to present and talk at this panel, one of the questions I had was exactly the point you just made, Mr. Blair, which was what is the scope of the framework and particularly my recent area of expertise, would I be a valuable addition to this panel?
So I feel compelled to touch a little bit on the scope of the framework at least for fear that my 15 minutes and flight down here from Boston would otherwise not have been as effective use of my time as I like to believe.
Let me back up for a moment: I've been in the healthcare industry for 20 years and for a large part of that time involved in myriad standards development activities. I'm one of those folks that Jim refers to who seems to have time for two jobs. I don't know where the time comes from for myself or my colleagues like Stan and others.
But, nevertheless, a lot of energy does go in by a surprisingly small nucleus of people to create standards for the healthcare industry. A poignant reminder, though, of how important this is occurred several weeks ago as I was giving a lecture at CHIMS which is the Colorado sector of HIMS at a monthly or quarterly CIO forum that they conduct and the topic of this particular forum for that quarter was about security and HIPAA and the seeking of practical solutions.
And I was charted with giving a discussion on one of the standards that's been relatively recent to the HL7 family of standards that has to do with context management. I'll talk about that later, but I found that giving a talk on standards is usually a dry subject.
It doesn't necessarily engender large audiences unless they're compelled by a giveaway like a free palm pilot or something like that if they stick through it. And talks about security which can be particularly arcane suffer from a similar fate.
So to give a talk about healthcare standards for security was a dubious distinction, particularly right after lunch. Nevertheless, I found, as I went through the talk and laid out a framework for how certain, not all, but certain HIPAA problems could be addressed in particular by some of the HL7 published standards and in the area known as CCAL, afterwards I was approached by a CIO who asked a follow-up question and when I answered her question for her, she gave me a hug.
Now, I've never been hugged after giving a public talk no less about standards and no less about security standards. And it occurred to me that as proud as I was in my speech and in my ability to communicate the issues, what probably also affected this woman was hearing a practical answer to some vexing problems that she faces in the healthcare enterprise. And a good part of the solutions to her problems were in the form of some relatively contemporary standards that addressed her needs.
So the opportunity to come speak here today in a forum that's looking at putting standards at a national level and putting some reason to how these standards would come forward at a national level is an opportunity I couldn't resist even if I suggested earlier, my present expertise is not on message-based standards.
Having said that, the addition, before I comment on the questionnaire that I'd like to add is, if we go back to some of the earlier comments which have been echoed earlier today from Stan's early comments to Jim's more recently about let's not forget this is about healthcare, this is about taking care of people, this is about keeping people well and making people who are not well better.
Challenged with how one builds practical systems as I have been over the last 20 years, led a number of years ago to a group of us to look at all the different aspects of the healthcare delivery challenges particularly as it relates to information technology.
And I hear today the desire and the need for data messaging standards and I'd like to use an analogy which is out of the broadcast TV industry. The broadcast TV industry has recently gone through a series of standards to define, I believe it's now seven standards, for the transmission of high-definition TV making various tradeoffs in transmission bandwidth and resolution.
But at the end of the day, those standards don't help most people set the clocks on their VCRs any better than they can today. And in the absence of being able to set those clocks on those VCRs, it can be difficult to record those wonderful TV shows that are now broadcast in 35mm quality like appearance and in digital surround sound.
My point being that there's two parts to the problem. There's the data transmission or the data messaging which is the bulk of what these hearings are all about. But there's also the aspect of usability and accessibility between the user and the computer information system to begin with.
In the absence of accessibility and in the absence of usability, as Clem pointed out earlier, you're going to get a mixed set of information perhaps low-quality information that no coding schemes or no automatic processing algorithm or schemes are going to improve. And worse yet, if people aren't using the computer information systems in the first place, there's going to be large holes in the datasets to begin with.
So I think one of the practical dilemmas that any standard-based activity needs to confront when dealing with the backend integration and messaging which can solve a myriad of challenge in healthcare from being able to look at datasets in the aggregate to see patterns in health and healthcare above effectiveness as well as what's happening in populations, to effecting the enterprise workflow so that as a physician, I can order medication which gets filled by the pharmacy.
The complimentary part which has generally gone unaddressed in the industry until relatively recent times is the interaction between the physician, the caregiver be they nurse, therapist or whatever, and the computer. I'd like to propose that that interaction and the set of standards that can govern and facilitate and improve the quality of those interactions not be relegated o a later task for this Committee, but rather to be something that move closer to the front burner.
That has two benefits at least. One is as I already suggested, it gets people using the very computers that we hope they'll use to produce the information that all the messages will be generated about. The second dimension to doing this is -- actually I slipped what my second thought was -- let me come back to that in a moment then. But the point is is to get people to use the computer systems effectively and intuitively and to put that on the forefront of what this Committee starts to talk about.
Now, within that space then if one accepts that, I'd like to touch briefly on what HL7 has done in this arena which is by no means exhaustive, but it does start down the path I'm talking about and it's particularly notable because HL7 has been traditionally know for its messaging standards which is mostly what you've heard about from Stan and others who talked about HL7.
But a number of years ago, HL7 realized that the space for standards and healthcare IT was broader than just messaging and charted several groups to develop standards and other spaces and one of those groups goes by the acronym of CCAL. The acronym actually no longer stands for anything, but what CCAL does publish under the auspices of HL7 are a series of standards for context management.
Context management enables applications at the clinical desktop or at any other point of use device, to share state with each other and with the end user. So we can be as simple, but as profound as the user selects that patient of interest once from any application, say a PACKS application, and all the other applications they're using whether they're client server or Web=based, it's a not a technology rooted stands, can automatically and instantly tuned to that person.
So now without necessarily having to have one physical repository and one set of database, I can access information from a variety of sources. And I remember my second point. My second point was is that these kind of standards, particularly ones like context management can also minimize if not obviate certain interfaces that one would otherwise need.
So it's not unusual now to see people deploying imaging systems and cardiology systems without requiring the transmission of the underlying data into a clinical data repository because that data can be accessed with a native applications directly by the end user and can be done so securely because the user can sign-on securely once to all the applications and safely because the user can select a specific patient once and not worry about differences in medical record numbers, name spellings, and so forth in the constituent applications.
So I see it as a very complimentary part to the objectives of the messaging standards that this Committee has set out to define. And, again, would like to propose that these kind of standards such as context management and others become higher on the priority list as a space for the Committee to discuss and to cover.
Having said that, it is challenging to go through this criteria specifically for messagaing standards and layer on top of it enhancements that I would recommend. So I've tried to be circumspect in touching on things that we've learned, particularly in defining the CCAL standard which I think we can extrapolate and are generalizable to any kind of standard and is applicable to the framework in the questionnaire.
So, first of all, in the general information, the request for separate information, separate statements. Later in the questionnaire in Section 5, the topic of dependence and relevance of other standards is talked about. But I think that in order to look at any standard and really understand what its role is and where it fits within the superstandards that may be out there, the dependency and the relationship of the standard should be elevated to one of the top five descriptions or answers.
I'm pleased to see questions about whether there are conformance, is there a conformance standard specified and conformance test tools available? I want to go to Point E because I just simply wasn't sure whether I understood it. What it says is "conformance standards specified."
If the question is, doest the SDL have specific conformance statements, then I'm in agreement that there is an extremely important element that needs to be teased out as opposed to conformance being specified by the vendor of a tool. In other words, I'd be looking for the SDO to make sure it has conformance statements that it publishes independent of tooling that might be commercially available.
In Section 3, under the characteristics of data quality accountability and integrity, I again go back to this concept of accessibility. This is a point that Dr. Rozen touched on earlier, but I think from a slightly different vantage which is, is the data accessible to the user, to the end user and what is required for the end user to actually make sense of the data.
For example, if I have a standard for representing image data or ECGs in a binary form, for most cardiologists I know, that's not going to be particularly useful. And most cardiologists are going to need some way of transforming that data into a user interface presentation that he or she can make sense of.
And that, to me, has to do with accessibility, usability. So the transformation of the underlying data to a representation that people can use both for input and output I think would be an important element to access when looking at the overall qualities of the standard.
In terms of indicators for market acceptance, I agree that looking at percentage of market penetration both across a vendor community and a provider community are important as well as within the government, but I think there's another dimension as well.
When at the end of the day, it's also important to look at who is using the standard. And the reality is, particularly for our industry, is that if the big vendors and the prominent large institutions are using a standard, that's probably a very good leading indicator that that standard is taking hold as opposed to being part of a smaller community maybe of small vendors or some, with all respect meant, some niche within the community. So looking at who is using the standard or standards is a very important criteria that transcends just the numerical percentage use in the industry.
Finally, a dimension to a standard that I take great personal interest in has to do with how easy it is to actually implement the standard. Many standards have gone to a certain point and then stopped in terms of their specificity leaving a myriad of details to be left for the developer.
And often those details which may seem low level and out of bounds for the particular standard, particularly if the standard has to do, say, with clinical care delivery to clinical processes, the absence of those details can lead to disparate implementations of the standard which don't interoperate even at the most fundamental levels.
For example, at a media level or the inability because of representation in a different byte format or whatever it might be, two standards that otherwise are compatible to implementation, otherwise compatible, nevertheless, can't interoperate because of some fundamental difference.
So I think it's extremely important to tease out with the standard many of the technical characteristics of how the standard is specified and what it requires. For example, I would start, first of all, with the philosophy of the standard relative to technology.
And they seem to fall into maybe three camps: those standards that are very technology specific and, in fact, require a certain technology and, therefore, go very deep down the technology stack. You can't implement this without using technology "X". It's inseparable.
The second type are technology agnostic. These are standards that assume no particular technology which can be very powerful in terms of flexibility, but then run into many of the interoperablity, practical interoperability problems that were referred to earlier.
The third is what I would call technology neutral which is what we tried to practice or I should say are practicing in CCAL which is, you look at a set of core technology principles such as many of the principles that underlie object oriented development and object oriented architectures transcend any particular programming language or system implementation.
And you define a standard around a technology neutral stance which means it's not agnostic. It just doesn't embrace any one technology. And then as the series of addendum of companion documents for popular technologies driven by the market, you define all the added details that are necessary to make that standard implementable in a particular target technology.
The beauty of this is that the standard can serve as an umbrella of consistency or semantics and meeting and policy need to be uniform, but enables different target technologies to be implemented for the low-level innards of communication and messaging and so forth between the different implementations.
One particular measure of this is whether the standard actually goes all the way down to the API level, the so-called application programmer interface, particularly if it's articulated in different technologies. Again,allowing choice, but, nevertheless, interoperability.
I think there are many lessons to be learned from some of the more contemporary activities that are going on. CCAL represents a lot of good practices that I'd encourage the Committee to take a look at. And certainly the role of information model and information model development such as HL7 is now doing with Version 3 represents another exceptionally good practice that I'd encourage the Committee to look at and consider in its framework.
Thank you very much.
MR. BLAIR: Yasser al Safadi is our last one. Let me check, Yasser, for just a moment. Kepa Zubeldia is on the phone and sometimes he can hear and sometimes he can't.
Kepa, are you able to hear Yasser.
DR. ZUBELDIA: I'm on the phone, but I would appreciate it again, speak closer to the microphone.
MR. BLAIR: Speak as close the microphone as you can.
I guess I should ask while we're setting up. Robert, do you have a copy of your testimony?
MR. SELIGER: No, I do not.
MR. BLAIR: Is that something you could get to us shortly?
Is there anyone else by any chance that didn't have a copy? We would really would like a copy so that we could capture your thoughts and ideas and integrate them into the next draft.
(Brief pause.)
We're still here, Kepa.
MR. SAFADI: Thank you, Mr. Chairman, Members of the Committee, Honored Guests. My name is Yasser al Safadi. It took me a little while to switch seats for the benefit of Jeff because I needed to get closer to the overhead projector. The cable is not that long.
It's my pleasure to appear today before the Subcommittee on Standards and Security of the National Committee of Vital and Health Statistics. I'd like to thank you for the opportunity to testify.
I'll introduce myself. I'm a Principal Member Research Staff, Philips Research. I led the project on Healthcare Interoperability in the year 2000)and now I'm leading the project on XML for Internet Devices. I Co-chair the HL7 Image Management SIG, also participated in Co-chairing the Andover Working Group DICOM Sig which turned out the IHE activities later. I am Chair of the Biomedical Imaging Working Group CORBAmed. Currently, my activities, I'm Principal Representative for Philips Electronics in the World Wide Web Consortium, Query Working Group and Protocol Working Group.
My statements will respond to the question that had been proposed by the panel. I'm very pleased with the proposed process for making recommendations to the Secretary about specific PMRI and it is obvious that great effort went into this preparation. For the criteria of the selection of message format, draft questionnaire, and proposed list of transactions.
During my testimony, I will share with you Philips' commitment to industry standards for patient medical record information. Hereby, I'm going to bring your attention to some considerations that I think will enhance the subcommittee's proposal.
Addressing the criteria for message format standards, I think as many have shared, that this is a valid selection. One thing I'd to reflect, I don't know how to measure and weigh those criteria and choose a standard to recommend under HIPAA. So those are, I think, very important, but I don't know how to weigh them and compare them and organized them.
However, this is intended to be an ordered list. I agree with the sequence of bullet items with the first three being the most important -- interoperability, data comparability, data quality, accountability and integrity. This slide, I had it written and it is not in the printed matter. I thought, for the benefit of the Committee, to put it as a separate slide.
To address the issues in the draft questionnaire regarding the message format, I would like to share with you my perspective about an indicator of interoperability that deals with conformance. In the questionnaire, there is Item E about conformance standard and then about availability of conformance.
I would highlight and agree with Committee about the importance of performance because determining whether a product faithfully implements a standard or specification is essential to creating robust, interoperable solutions. I would highlight also the role that I would like and see more of the NIST Institute increase its activities in software diagnostics and conformance testing.
I see that NIST in collaboration with healthcare SDOS can disseminate knowledge on testing and quality assurance activities, develop jointly test suites, tests and diagnostic tools that are intended to complement the SDO's specifications and provide their facilities, which they have already done to CorbaMed for World Wide Web Consortium, to hold workshops and forums.
I agree with the proposals on the questionnaire and I think the benefit from my point of involving NIST is that I would like to see a better test tools composability. Personally, as a vendor, I would like avoid a stage where I'll have to maintain and back track and to have engineers trained in order to reach new test suites or more that I cannot compose when inputting a product that will use -- and DICOM and some Web standards.
Regarding the draft questionnaire dealing with characteristics of data quality. It asks how does this standard and/or implementation guide maintain or improve data quality? And it says promote standard data definitions and measures.
And I would like to add a little bit more to it. Just having the data definitions alone, would not be enough to achieve interoperability. I would promote and suggest that SDOs provide and adopt definitions for character models, digital representation of characters, transcoding, normalization, and overall adopt a reference processing model for that element and data.
And this expands actually a point that my colleague, Rob, mentioned about the media formats and interoperability. With the advent of the Web, we have interesting cases that we did not address or deal with before. Our perception of characters as units of a writing system or use for aural rendering, visual rendering, for input, collation,
and storage.
Those notions are now we are looking at them to be used in many, many interesting ways and with the current standards without the adoption of reference processing model, it will be a very difficult and painful in order to implement a new software that makes the benefits from those.
And I share the point that Fred Behlen made earlier that adoption or these simple measures will be on a very high step. I think the benefit will be a consistent, interoperable data manipulation, which means compatination of strings between DICOM -- and yet another standard need not to be a rocket scientist.
I'll highlight also the point for the consistency with other standards. Here the questionnaire asks, "Describe the relationship with other standards such as inclusion, dependency, interface, overlap, conflict or coordination. I would like to think at least the purpose is to collect information and the purpose of this collection of information to promote a behavior or a tendency in healthcare standards is to ask that the emphasis will be on technology and Internet standards and international standards.
I would suggest that healthcare SDOs should participate in technology and Internet SDOs to ensure that these technologies can meet healthcare concerns. For example, we are witnessing now the second revolution of the Internet. Before, it was a library. We use the metaphor of browsing. In the year 2000, we see that it is changing. It is becoming the -- of access and retrieve. The Internet is a huge database that we are able to access and retrieve, not just for humans to look at, but probably for software agents to search and retrieve content from it.
The second change has in the Internet domain, that it is a loosely federated environment for service provision and we notice now with the standards for XML protocol, for example, where you will be able to invoke services on almost any Web server. It is providing lots of promises for business-to-business and business-to-consumer and this new trend.
I would highlight the importance of the World Wide Web Consortium and the participation of healthcare SDOs in these technology and Internet standards. The World Wide W3C is working on recommendation for XML protocol, query, transformation, device capability, schema, what they call the semantic Web, and I heard from many colleagues that they think XML is very great.
However, when I'm there, I'm seeing reflection and input and criteria provided and participation from the model industry, from financial, from banking, from manufacturing. However, only minimum input is from actual participation in the schema work group.
We don't those technologies being addressed to make suer that the first round or second round would be able to address healthcare concerns. I see this because the benefits will primarily accrue to the healthcare system as a whole and not to only one vendor or one group. That's why I'm promoting this wide participation.
In addition to the scope and relationship to other standards, I would really emphasis the issue of international standard organizations. Healthcare organizations should establish liaisons with internationalization activities not only with healthcare international SDOs.
So it is not only just the thought, as has been expressed, of business processes of best practices that we could learn from Japan, UK, and Europe, Australia, but also what does it take in order to create a software and to create a standard that could be used also by the international community.
I also share Stan Huff's concern that we don't want to be held and delayed until we reach international agreement, but I think our participation of US subject matters in these international standards is very vital to promote our interest.
The benefit I see from a vendor's point of view is that it enables US healthcare information system vendors to compete effectively in the international marketplace which means that the software I'm selling here in New York, I'll be able to sell in UK, Europe, China, and the Far East which means I'll be able to lower down my costs and many other benefits.
Now, this is a topic that has been addressed and I'd like to emphasize much more is the timely standard development procedure. The previous relationship to other standard dealt with a scope and whether there is an overlap and who is doing what.
However, I notice from the questionnaire that mostly when it dealt with the timely standards development procedures, it addressed the intra-standard procedure and not the inter-standard. And I would suggest to add another item asking what processes that are used to expedite the standards development cycle when more than one SDO is involved?
I think those processes need to be in place to expedite this collaboration because I think more standards, some of them are now but in the future, will be joint developed. It will not be developed in one silo called HL7 or one silo called DICOM.
We are seeing now that both in terms of structured reporting requires the collaboration of these two organizations and understanding that standard development processes are by nature slow in order to permit due process. I think it becomes more problematic when it involves more than one SDO.
One suggestion I have is that SDOs can establish enhanced coordination and process preferably at early phases of the standard development, preferably at the requirement gathering phase. And the benefit of it is a timely inter-standard development procedures.
We need to get it fast and we need to --- and this also relates not only to DICOM and HL7, but also relates to HL7, DICOM, and technology standard. It goes beyond that. I understand it requires much effort in terms of this participation. However, I think the benefits are great.
In addressing the proposed list for PMRI
transactions to be considered, I'd like to mention just a little simple suggestion regarding transaction Number 5 that deals with radiological images. I suggest to change this wording to include medical images and waveforms as medical images include still dynamic sequences or realtime streaming or video. The current wording affects only to radiological images.
Again, also for point Number 3, the laboratory and diagnostic study result for laboratory and diagnostic systems to EMR and HIS systems, I would share the current standard being developed for structured reporting which Philips supports and as DICOM and HL7 collaboration where we this cross-SDO collaboration happening and we see that this standard, as it captures the clinically specific information more accurately, it enables outcomes analysis, it promotes administrative efficiency, and improves individual healthcare.
However, when I'm citing these benefits for this standard, I'd like to learn how the respective committee is going to provide a weighing mechanism or a measurement in order to understand which is applied and which is adopted and that leads to my very initial comment.
I'd like to thank you for your attention and the opportunity to testify and I welcome your comments, feedback. Thank you.
MR. BLAIR: Thank you, Yasser. Do we have anyone else? That's it? Wonderful. Okay. Here. Let me just check the time here. Should we have a 15-minute bio break?
DR. COHN: I think you ought to go to questions now and then maybe have a bio break then and keep on going?
MR. BLAIR: Before the questions?
DR. COHN: Yes, because people have ---
MR. BLAIR: That's just fine. Then let's do that.
DR. COHN: Dr. McDonald, did you have one? Did you have a question?
DR. MC DONALD: I've a number of questions, I guess, and comments, but I won't be able to get them all out. A couple of statements were made about thin browsers. So, which one? I mean talking about standards. I've got to worry about that statement they have to connect with thin browsers because we can't make it work, but each time, it's a separate effort depending on which one you pick.
The issue about the market picking versus some other force picking, I think that's a challenging item. I'd like to know what the other force is. A couple of the speakers said it shouldn't be the market. You should consider emerging technology. Who decides? How do you know when you're not into the future, what has emerged? How do you choose beside using some market-like force? Wise government -- I think the gentleman who actually gave that proposal --
MR. BLAIR: Are you addressing this to a particular individual?
DR. MC DONALD: Yes.
MR. BLAIR: Mike? Maybe Mike Rozen?
DR. MC DONALD: Yes, yes, yes. I'm sorry. I didn't get your name.
MR. SELIGER: I think my main point wasn't to say specifically that the market choose. It's look at market forces in context and I got the impression that we were looking at penetration and market success solely within healthcare. And I think Yasser gave an example of XML where manufacturing and some of these other industries are sending a very strong representation to the W3C and we need to look at market forces across domains.
And in other vertical markets, they may be solving problems that are very similar to what's happening in healthcare. I can't remember which speaker brought it up earlier, but someone was mentioning that we need to essentially pilot test some of these standards -- it may have been Stan.
I think that that's a good example where something
has had success in another vertical segment and is promising. We need to try it and recognize --
DR. MC DONALD: This is still a question. It's usually we the government when you say "we." I mean who cares enough to pay for it is really what the difference is. That's what market force sort of says. The XML one is a give me because I think at least three of the standards groups in healthcare work with XMLs.
So we don't have to give that one a plus. I'd also comment that there has been three or four of the proposals that the healthcare made and XMLs were kicked, rejected. In fact, they feel pretty powerless on the big monster XML. I can speak in specifics later, but they're not very receptive to little healthcare, the technology companies or haven't been because I know people who are going there and making proposals and getting (pugh).
That's a separate issue, but you're still talking general terms about the technology and I still have to come back to is if we're going to bet on the future, how better can you do it than what the community-at-large, who's smarter than the community at large making these choices with their pocketbook.
I just worry when we get this vague thing about it's going to be market forces and me personally or market forces and my buddies over here or market -- who else is there that can get an honest answer, an unprejudiced answer? Market forces and my project team -- who else is there?
MR. SELIGER: I don't know if I can answer that specifically. I can draw on one example in the OMG. There's been a lot of criticism or public interest, I guess, in some of the specifications that have come out of the healthcare domain taskforce. In particular, are these specifications being used? How are they being used?
And one way that that's being discovered was to create an interoperability award and find out who's using it. Filintree(?) Business Models is a little different than some of the other standards development organization in that they give the standards away.
`So you don't know who's buying them because you can just go to the Internet and download them. So there's a real issue with knowing who's actually applying these standards. So the challenge that's being faced in that community is understanding who's using it.
What we found out as a result of that award that there are actually a number of large commercial vendors. Actually, the winner was McKesson HBOC (?). So there is some market industry-at-large that is applying that particular standard. I don;'t know if that answered your question or not.
DR. MC DONALD: No. I guess what you're saying is OMG should be considered; is that really what -- I'd consider them a minor player, but you may be telling us --
MR. SELIGER: That was certainly one of my points.
DR. MC DONALD: You're from OMG?
MR. SELIGER: I don't know if I'm from OMG. I participate in the OMG processes, yes.
DR. MC DONALD: That's what I always hear why people besides market forces.
MR. BLAIR: Could I add in to just, you know, on this issue, maybe to help a little bit is that if we're looking at this question, it's really hard. And OMG isn't the only SDO that has difficulty keeping track of its market acceptance.
ASTM has mentioned the same thing. Even with an HL7 which has a pretty good feeling for, by the number of attendees, the number of vendors that say they're HL7-compliant, the actual number is not known. The attempt here, and maybe there's a better way to do this, was to give individual SDO's many different ways to try to represent what they feel is the degree of market acceptance.
Some may be able to identify vendors, some may be able to identify government agencies, some may be able to identify providers in some ways and we even wound up indicating, if you can't do those, if there's some other indication of market acceptance.
So the attempt was to give a plus wherever a plus could be found or wherever some quantification could be made. So, we're not saying that you have to have penetration in all of them because you probably can't measure them all. Maybe you can't measure any, but that was the intent.
Clem, you have more questions I think?
DR. MC DONALD: I don't think you want me to keep harping on that, but it's just that it's the only good -- and whether you can measure it or not is another set of stories -- but my belief is that we can't foist on the American companies things that are in development.
This would include those things within the standard organization which may have some successful parts to their group. It's early. It's further along, but this new stuff just popped out and the goal here isn't to make a success out of the standards. My perception is to kind of help along the things that are already ripping along. The world will still change. New things will still come out and the market will decide. That would be my whole thing, not have government deciding.
DR. COHN: Other questions? Please, Yasser.
MR. SAFADI: If you please, I'd like to address the concern about participation specifically for World Wide Web Consortium which I am very actively involved now. I think the technology companies would love to listen to healthcare when healthcare presents itself as a group rather than as an individual.
And this is why in my presentation, I suggested that the benefits accrue to the healthcare system as a whole, not for an individual vendor. So when the technology companies -- IBM, Microsoft, to name many among others -- they'd love to sell their components and their software, their databases and their Web services to healthcare provisions in order to deploy it in that market.
I think how the interaction and the liaisons between the SDOs has not been formerly set or is not well represented in those organizations, in the technology, and I think this is one of the factors that led to the dismissal of those comments.
However, I'm very surprised because I'm involved in those two of those working groups and it is very difficult to dismiss any requirement. It is very difficult. World Wide Web Consortium works on a consensus basis and this is, I think, to the benefit for us in healthcare that we are able, at least, to provide our requirements so they'll be able to build the technology that we would use.
One concern I would have, and this is why I talked about expedite, is the impedance mismatch between healthcare, SDOs, and other Internet SDOs. In healthcare, things take a long time. A long time means two and three years before we start seeing implementations.
In the Internet domain, it takes two to three years tot have a standard. Over interim, we'll find implementations that are trying to capture the market or at least to learn what it means to get to the market. So understanding that, it is a culture change also that needs to be done for the SDOs and for us in our domain. And it is different from the interaction with other healthcare SDOs other than this is a new market or a new force that will affect us. I hope this answers your concern.
DR. MC DONALD: I think it's true. The only one I think who is active there, that meeting was HL7. I was not there and it's just very difficult for them to get voice, but Microsoft's a lot bigger than HL7. I mean there are some big players on that thing and there was one regarding date representations and they were just sort of smashed down. Everyone went the Microsoft way.
DR. COHN: Bill Yasnoff?
DR. YASNOFF: I have a question for Chris.
Chris, in your discussion of barriers to access, you touched on an issue that's been discussed here before which is this issue of what to do about the problems that occur once a particular standard is selected as the standard and thereby a monopoly is created. Do you have any suggestions for the Committee about how to deal with this problem of establishing a monopoly through the selection process?
DR. CHUTE: Well, at the risk of having Clem suggest that it's not market forces -- I'm not smart enough to know the answer to that. The two proposals that I made in the presentation boiled down to a public buy-out, if you will, so that it becomes practically public domain and might evolve from there or some kind of regulatory arena where the revenues that derive from sales of mandated standards can legitimately be used for development, maintenance improvement of that standard, but cannot or should not be used for other programmatic purposes within an organization.
In other words, you shouldn't be able to funnel profits into alternative uses that are a windfall, if you will, to that organization. That would constitute, I presume -- thank heavens I'm not a lawyer -- but I would presume that that would constitute some kind of regulatory reality. And whether or not that's even reliable is unknown to me, but short of those two alternatives which is frank buy-out and regulatory, I'm not smart enough to see how it could be done.
DR. COHN: Mike and then Clem.
DR. FITZMAURICE: Question for Mike Rozen.
Mike, in your testimony when you were offering suggestions to facilitate criteria for selection of PMRI standards, you talked about patient and consumer health records and integrating some patient-reported information, health risk assessments, -- to the health care system's medical record.
My question is: Are you proposing that there is a need for standardization of patient-reported information maybe creation of templates? And, if so, then who should do this? What standard developing organization? Or would you propose that the government do it?
DR. ROZEN: Well, I would never propose the government do it. I think what we need to have is recognition and at a higher level, I would take your questions. First of all, recognition that that information needs to exist within the confines of whatever is considered to be the patient's medical record be it a PMRI or a blend of a PMRI and a consumer health record.
It's kind of broached in the PMRI discussion where you talk about history. But where it loses it's flavor is that it talks almost in the past tense rather than in a current dynamic state. And what we're talking about is that people have health risk characteristics that are somewhat behavioral driven, somewhat genetically driven, somewhat driven by other things, but all that is in an active state that needs to be monitored and put into the record.
It has tremendous value to the healthcare system. So I would start at the highest level by saying the recognized need to include that into the record. I think that individuals in private industry, there's plenty of scientific studies about how to do this and how to go about doing it that can help.
The greatest difficulty, I think, in the question you ask is one of semantic interpretation. How are you going to interpret what a patient of a consumer says into medical terminology. We have spent three or four years delving into that, working with the UMLS and other standards organizations to try to come up with consumer health catharsis currently that has over 23,000 terms in it.
And we feel like it's still in its infancy. If there's a 126 medical ways to say hypertension, how many more ways are there in the consumer world, but yet I want to know when we bring that information into the medical record that we're both using the same language. So that would be my response to you.
DR. MC DONALD: I just want to get back with Chris's comment just to clarify or you maybe what I think you were talking about or maybe not. We were talking about the message standards which maybe too narrow a scope, but the monopoly situation isn't very deep there.
So if CCAL for this context which is deemed as a standard, every vendor in the world can use it for 250 bucks. He just has to buy the -- there's not a usage per use cost and there's competition among the vendors offering it.
In X12 is now the standard for the first batch of, and I think they did get cash. They got $750,000, I think, to make the copies free, not even their usual small licensing fee. Now, there's other contexts whether it be a per-use like in vocabulary. I was guessing that's what you were really thinking more about and you're worried about that situation.
DR. COHN: Are you nodding your head, Chris?
DR. CHUTE: Yes, I express surprise that Dr. McDonald would suggest that I had vocabularies as an interest.
(Laughter.)
DR. COHN: Let me ask a different question in a different area for a change of pace. I won't ask about terminology, but I am sort of curious. A number of you mentioned about efforts that were cross-SDO.
I know, Yasser, you made a particular point about this one and recognizing that we're going to get more and more areas where there's either competition between SDOs or where there seems to be handoffs and you start to see that with claims attachment already, certainly some of the work going on with DICOM and HL7.
Maybe I don't understand the whole SCRIPT standard, but it seems to me to be a piece that's HL7 and piece that's NCPDP. And I think we're seeing more and more of this. Now you wanted people to address issues related to how well they can function in that environment? Actually, I should comment that one of our members almost lost his shirt at one point trying to get SDOs to work together very closely on standards as I remember.
Yasser, HIPAA, can you comment on that? And other comment about the issues and what we should be looking for?
MR. SAFADI: There are, as I mentioned earlier, issues of scope where at least for the benefit of understanding, we would like to learn where each one of them proclaims to be its territory without trying to agree whether it is their rightful territory or not, but at least we can make a statement of that that will be really helpful.
MR. BLAIR: Can I understand? You're saying: What is the scope of this particular message format standard that an SDO is proposing as a candidate? Is that what you're saying the scope is?
MR. SAFADI: This is true. This is the initial questionnaire. However, later, how does this particular standard thinks the others, how does its scope relate to the others and I think it would be interesting to find out their perception versus reality of cross perception.
DR. COHN: I guess the question is: What process is used to expedite the standards development cycle when more than one SDO is involved, which is what I think what you're talking about here.
MR. SAFADI: This is the second point is that about process. The current suggestion in the questionnaire has to be intra is the order, how internally within our silo how we can speedify the process. However, I see absent other than a statement of liaison. We talk to them sometime, but there is no formal process that engages either collocation of meetings or gathering, soliciting information or notifying about events. There are many mechanism that could be employed in this process and I'd like to personally learn and see what is being put in place.
DR. COHN: I guess I'd ask maybe the subcommittee and the other people: Is this a small issue that's really not very important or is this an important set of issues? Only because, as I said, I'm seeing a number of the standards look sort of interesting are being things of multiple SDOs are having to work on. Maybe we'll start here and then I'll ask Clem only because I'm looking at him when I asked this question also. Please.
MR. SELIGER: I'm not here officially representing the VHA, but I'm going to speak from a little bit of VHA experience. One of the activities that we've taken on in VHA was trying to do a "crosswalk" of international models because what we were looking to do is to leverage as much work that's been done as possible just for our own benefit.
And when we looked at just standards in those spaces of models, it was amazing how disparate some of the activities were and instead of trying to classify models for ourselves, that ended up being fruitless. And what we did instead was approach each of the organizations that had a model and ask them to classify themselves and that got us a lot further along.
I'd strongly echo what Yasser, HIPAA was saying in that if there were a vehicle where standards organizations can say, "This is our sandbox. This is where we see ourselves playing." And maybe that extends further into a particular messagaing standard. I think that provides great value both to this group and to the consumers of these standards.
So as I'm looking to enable technologies within VA, I can make better decisions because I know that HL7 is considering this their space and maybe as an independent assessment, I think that they're the standard of choice. But in another space, they may not be the standard of choice. So I think any sort of objective metric that can come out of here to let SDOs classify themselves, would be of value.
MR. BLAIR: Clem, do you have a comment on this?
DR. MC DONALD: I mean the problems are of two kinds. There are some other collaborations that maybe aren't as famous, but NCCLS and HL7 where they literally divided up the part that they published and they cross-published it. So they both can publish each other's parts. That is a very attractive -- where one has some overlapping expertise.
But the problem is as you said. I did do a struggling activity for a number of years to try to have one big cross-published standard of all the standards groups and I won't give you my internal beliefs about really what caused what to happen and when and where. But there's a little bit of terror amongst --
I guess what it is in America, you can't make anybody do anything so you shouldn't start out trying. It really was the bottom line I learned. People who want to mutually cohabit, mutually cohabit and those that don't, don't and you let it be how it turns out.
And that what happens is smart people figure out what's really going on where and they join up. And a lot of the efforts we do at this high level, we screw that up because smart people figure out who the powers are and where the masses are aggregating and I just worry that we're going to screw that up. The marketplace is kind of sorting it out and deciding.
What happens in America, I worked with CEN for while, they are funded, at least they were funded to do standards and the tendency was to continue to shrink your scope because for the same funding, you had less scope. In the where it's all voluntary, everybody is always expanding their scope. They're always crashing into each other's borders.
So whatever borders you come up with today, they'll be some new kind of crashes at the edge tomorrow. There is a nice document that I put together last year that you can get that does summarize a lot more detail than what's in this questionnaire. This questionnaire's goal was to get us, within a finite amount of time like a year or year and a half, to make some early first cuts at standard suggestions.
It was also our belief that these will not be mandated with the force of the administrative standards. So there will still be room for the world to play and grow and change and modify and mutate, that these aren't going to give anybody absolute rights, eminent domain or whatever the heck it is that they're going to have all power.
That's our guess. It's just too complicated still and it would be presumptuous to try to impose some extraordinarily powerful and punitive sort of enforcement policies on its use, but encourage the heck out of those standards that we think at least are far enough out that they're kind of really relevant.
MR. BLAIR: Could I?
DR. COHN: Yasser, HIPAA had his hand up.
MR. BLAIR: Oh, I'm sorry.
Go ahead, Yasser, HIPAA.
MR. SAFADI: To respond to you, I agree with you that it might lead to a mess. And this is why I would promote at least in their processes, there should be something that talks about speedy procedures for interstandard or inter-SDO collaboration, not necessarily within healthcare organizations or healthcare SDOs that think there is a perception of competition, but at least that there should be a process that how a certain standard is working with a security, with the Web. If there is a procedure that reflects that, I would like to learn about it.
DR. COHN: Jeff, it's your turn.
MR. BLAIR: Michael, I feel like you felt like you were a little out of step and I don't want you to feel that way. I really want to ask you a question. If you heard Clem's last comment which was that as we've begun to look at standards for patient medical record information, it appeared to be many times more complex, many times more sensitive, the consequences of making a mistake were many times more severe than the financial and administrative transactions that have already been adopted under HIPAA.
And so, what we were asking all of you to look at was what we thought a small piece, a first step, the lowest risk area. And even when we look at that which is standardization of message format standards, you could already see how complex that is by itself.
And the reason I'm saying this is, Michael, I don't know if you understood that, but if you do understand that this is only a small piece of it and that there's many other areas of standards to look at in the future and then the other piece is there may be a good part of the evolution of care data communications that we don't want to standardize.
And I would think that there are things that WellMed is doing right now that you don't want anybody to start standardizing. You're a pioneer and if lack of standards allows you to do a lot of things which may eventually, through market acceptance some years down the road, become a candidate in itself. But we certainly don't want to standardize the functions. We just want to enable the interoperability and comparability.
And so, in short, given what I've said, do you feel as if rather than being concerned about what we're doing that you might feel a little less concerned and realize that you have a free hand to be a leader and a pioneer in the area that you're working in?
DR. COHN: I'll let you answer and then I want to make a comment too.
DR. ROZEN: Okay. Thank you, Jeff.
I did not do my presentation to try to present that there should be an area that you standardize. Far from it. We are doing what we're doing and we are out in what I think in a unique area, cutting area that's totally changing very rapidly and will outpace any standardization effort that I see occurring at this point.
But the derived standards that have been brought forth so far are very, very useful to what we're doing. For instance, our consumer health thesaurus maps through the UMLS. We use the drug databases. HTTP is our communication media. We use XML7 with HLA where it's available. The point that I was trying to make was to take it to a higher plane and what concerns me in your doing this as your first step is that you not lose sight of a bigger picture that I still feel is incomplete.
I still feel it is the old model being dragged back out instead of a new vibrant model that needs to be implemented. And I guess I didn't really get that point across enough, but I see as one of the critical factors throughout the entire standards process has to be an emphasis for availability of the information.
Whatever standards selected, underline it needs that information is 7X24 available and if that means that you have to put every standard against the Internet to make it happen, then that's what you have to do.
MR. BLAIR: Yeah, but at least in my mind, 7X24 availability is a system functional capability. I don't see that as a standard for communication. If you want to run any standard 7 days a week, 24 hours a day, you can. It's not that one standard can do it and another standard can't.
DR. ROZEN: I agree with that, but I don't think there's a recognition in this that the information needs to have that kind of availability. What we run into, what I find so frustrating in the healthcare industry is the information is truly not available. If it can be posted, I have the technology today to go get it, to interpret it, to bring it in existing today. What I find is the information can't even be posted.
And we work with most healthcare organizations at that level. So having standards that talk about messaging, even within their own organization where they have great messages, and then the physician because he's at home can't access that system or gain that information.
That's why I brought it up. It's more in the PMRI that I find it missing. In terms of the standards as you present them and ask for our input, the first thing I would weigh would be interoperability because it allows us to do so much of what we need to do and want to do.
DR. COHN: I was going to make a comment and I think Dr. Chute also wants to comment. I actually was not so quick to take his comments off the table. Now, of course, I screen a lot of your comments and I guess I heard what I wanted to hear, but I did hear and I sort went, hmmm, this is something that we should be thinking about had to do with the patient/physician interaction.
And it may not ready. You may decide that, but to completely dismiss that interaction and that set of transactions is probably a little premature out of the box to just say, "Well, you don't even want to think about that one." And we may want to be asking a question or two to see if anybody is doing anything about that. That's what I heard.
Dr. Chute?
DR. CHUTE: Thank you, Mister Chairman.
At the risk of time logging this discussion a little bit, permit me, if I might, to return to Clem's observation regarding interstandard collaboration and cooperation. I asserted as my third point the desirability of these, if you will, overriding metastandards to facilitate communication.
Clem, you asserted and I think you're correct, that smart people essentially went where the action was. And that has resulted, not that this is fundamentally bad, but that has resulted, if you will, in a megastandard, a single SDO more or less dominating and increasingly dominating the health information industry for want of, I submit, an adequate form where standards issues can be either on a bilateral basis and you've pointed out some examples of that of ideally, on a multi-lateral basis where there can be agreement, consensus, concurrence as to who is best qualified to undertake a given strategy.
Now, perhaps the opportunity to ever achieve that is virtually lost. I don't know the answer, but I am interested since you have had such intimate experience with this, whether the emergent model we see of a mega-standard de facto taking over within itself these interstandard interoperability kinds of issues is a preferable situation.
DR. MC DONALD: It's a lot better than what I was in trying to get all six standards groups to play and then felt pretty much like I couldn't walk down a street without looking around my back. I would go into details, name names, but I won't. Maybe sometime at a bar.
But some of the standards got terrified of the notion of losing their autonomy and the terror came related to the funding flows and I think I added to the terror when I used the word like "let's make them free." That was really dumb because I think there's still ways to make money to get the cashflows and still have it be free because you really want it to be out there.
So what you need is some controlling organization and I think now the two choices were we get together and we deliberately collaborate or let the markets play it out and I think my theory is, it's working out pretty well because we at least have a way that people have to talk to each other seriously about the conflicts. They can't just pretend like it's not there and re-publish the stuff in a different way and create confusion.
But even better with these newer models where you have powerful big organizations, NCCLS is one. For those of you who don't know, this is a big laboratory standards. They deal with the actual chemical re-agents. They deal with how you make the mechanical parts in laboratories and they're very large. They just voluntarily said this will make sense.
You guys do the message standards, we'll do the trays and the bottle sizes and the mechanisms that go into laboratory automation. There are other opportunities like that where you really have a collaborative done voluntarily where they come in and say, "I want to do this. You do this, and it looks like we're both mutually suited."
DR. CHUTE: Is there a forum where that could accelerated?
DR. MC DONALD: You know this acceleration is the word that's been around since Newton's time, I guess, but we've heard it in the standards business forever. It's as though that there are some silly window that if we just got through, but this stuff is just deep down hard. If you look at the models. I got a model -- They're talking like hats and trains. They're not even related. They're both calling it a health model. One is sort of an administrative structure model talking about how their agencies connect.
The other one is something you go bits and bytes about. And it takes so long to percolate this stuff up because we're not talking about a CD drive which is really easy stuff. Here's a drive. It's a box. Stick anything you want in it.
We're talking about all the informational knowledge and awareness of that information going in. It's like having to standardize songs. That's what we're trying to do in healthcare and it's way harder than these other kind of standards.
DR. FITZMAURICE: I want to follow onto what Clem was saying. It sounds like it would be pretty easy if we ask the industry what standards are really ready for primetime. And then, why don't we have the government just mandate that everybody uses it? Let's do it in 1966 and in a couple of years, they're going to be nationally mandated.
Well, we did that with HIPAA in 1996 and here it is 2001 and we're still looking at the problems of getting a standard in place and adopting a standard that everybody agreed was ready to go back in 1996. These people came in and lobbied Congress for these particular standards.
And I got to conclude somewhat the same way Clem does that it's helpful to have a prodding hand at one point. It's helpful to have money and expertise coming in at another point, but it's awfully hard. It's hard to get people to conform and it's a lot easier on financial data.
A dollar is a dollar. A claim is a claim if you can define it pretty well, but I just want some additional information before I pay that claim. I want to pay differently based on the site of care not just what you did to a given person.
So people work up their work-arounds, their own ways of handling these things and to overcome that, to say, well, since people do this, why don't we have one standard way of working around paying differently by site of care for the same procedure and the same physician. It's not all that easy.
We get in the government, in HIPAA, we get the states coming and saying, "We do it differently. Wehavee our own coding systems. We want to use our own coding system." Well, why don't you just report them to us nationally, we'll take all that are alike and give them one number and those that are different, we'll give them two different numbers and that's moving along.
We're shrinking down the number of those, but it wasn't as easy as we thought it might have been back in 1996. So, here what we're saying is for something that should have been easy, we think we got the process in HIPAA and it's taken some time.
Now, we want to extend it, we want to broaden ourselves. We're so flush with almost success that we want to flush ourselves again with clinical data standards (laughter). And so, we're proposing, at this point, a somewhat new process for "tell us what standards you think are getting closer to prime time for clinical data, for patient medical recordinformationn standards. Let us look at it, apply criteria to it, justify making a recommendation, and then recommend them to the Secretary of HHS."
As Clem said, we don't think they're going to be stamped with mandatory "you get a $25 fine or $100 fine." No, we think that it's like putting out a seal of approval at a point in time. It's like putting out "here's a uniform hospital discharge data abstract set, a uniform dataset for nursing information, for nursing home information."
It's something people can build off of. It's something that the market will either coalesce and begin adopting faster or they'll say, "No, we got something better." But in either case, we're going to have better information about standards and greater national awareness.
There are more people in HHS that know what HIPAA means and can spell it than there were five years ago who know what transaction standards were. It's becoming more and more important for our own programs not just the programs that exchange this kind of information, but there are programs who have to give national guidance, national policy recommendations and need information to make a judgment.
They want some uniformity to this. So standards are becoming more and more important. Thank, in good part, to a lot of your work. Thank, in good part, to a lot of our work, and because some timing on this. We've got faster computers, cheaper storage. The timing is right.
I don't know what to do to make it faster. I would like to accelerate it. I can remember Ed Hammond proposing an acceleration process and it'll cost, well somebody else put a price tag on it, but $40 million. I'm not sure if we had $40 at that point, that we would be any further along than we are today. Some of us would be happier, flusher perhaps. This is a try, but hard effort by people is probably paying off more than the government saying, "We're going to put some dollars here, we're going to put some dollars there." But all of it I think is necessary.
DR. COHN: Jeff, do you have a comment?
MR. BLAIR: Yes. There's a lot of good suggestions, additions, modifications, different perspectives that we can begin to incorporate based on your testimony. I'd like to ask all of you to comment on what our subcommittee is considering for this next 12 months. The next 12 months, please understand, is only the first phase of the process of recommending standards for patient medical record information.
The reason that we didn't include in the letter that you received what the next phases were is we're not at the stage where we have specifically agreed whether the next phase would be medical terminology or whether the next phase would be content or whether the next phase would be middleware.
We're not sure yet. We'll probably have, maybe some more solicitations for guidance as to what would be appropriate and maybe nine months from now, we'll be able to see things crystallized where we know where to go, but for the next 12 months here's what we are visualizing and I'd like you to critique on whether you think this is a realistic procedure for us to go forward on for this first phase of standards for message format standards, selection of message format standards.
We were talking in terms of modifying this questionnaire based on your input and distributing those to all of the SDOs that indicate that they might have standards that should be considered, looking for the SDOs to give feedback in probably a 30-60 or day period so that we would have them back in June. We would compile this information, probably put it in some matrix or tables or some other ways for us to be able to analyze this, look at this in the August/September time frame.
Probably at that point we'd wind up having questions because as the data comes back, it's not all going to be mutually comparable data and it will probably raise new areas where we realize we didn't have wisdom to know what the right questions are today.
And we'd probably be coming back in the September/October time frame to a number of SDOs and asking for additional information and clarification. And then pulling that together into a report probably in the November/December time frame, having that report distributed to probably SDOs and other medical informatics leaders and providers and users and all the stakeholders that are out there in January so that we could submit recommendations by February of next year.
And the recommendations, as Clem has indicated, are probably unlikely to be that we're saying, "These should be adopted for everybody to implement." But probably some more circumspect form of trying to serve as catalyst to move the industry forward in those areas where we can and being careful to not overstep where it may be applicable.
Now, given that I've sort of laid out this general thought process that our subcommittee has, could I ask you to comment whether you feel this is realistic or inappropriate? Have we left something out? What are your thoughts on that?
DR. CIMINO: Jeff, it's Jim Cimino. I just have three words -- go for it. I think that you've done a good job enumerating the issues and I think there are organizations out there that are ready to respond to those issues and I think that more discussion about collecting more of the issues won't serve any purpose.
DR. CHUTE: Far be it from me to hold up progress. I concur. It would be prudent to initiate that data collection process. However, I would urge that you consider at the same time while you're collecting this information beginning to develop some, again to borrow Jim's words, desiderata, of what you think the answer should look like so that you have, if you will, an internal standard to compare the information gathering process against.
A standard to which to hold these kinds of answers because it's very clear. It's implicit in the questions what you're actually seeking and I'm only suggesting that there may be benefit for all parties to make it not implicit, but explicit.
DR. ROZEN: I think you should move forward on the path you've chosen. I think it's a clear path. I think also simultaneously, you should send a message back up to the PMRI folks that they should re-examine the PMRI to make sure that it really is apropos looking forward and not just looking back.
I go back to a comment that I heard a number of times since medical school and that is, who are you, where are you going, and what do you need to get there? And if you clearly don't know where you're starting from and what you're seeking, then it gets a little more difficult to know what the metrics are that you got there and you got what you really wanted.
And I'm really afraid that the consumer input is going to be lost or the patient input is going to be lost in this process if it gets too far down the road.
MR. BLAIR: Michael, you said send the word back to the PMRI folks.
DR. ROZEN: Assuming this is just a subcommittee, my message would be to the whole committee that I think it ought to take a look at the PMRI. I know a great deal of work has gone into that, but I still think that the vision needs another looksee.
MR. SAFADI: As I understand it, you have now the questionnaire that you'd like to circulate and collect feedback.
MR. BLAIR: A little closer to the microphone.
MR. SAFADI: I'll repeat my sentence. As I heard and I understand that you have the questionnaire that you are going to circulate to the SDOs and collect data from them. After collection of data, you are going to compare and process it and the suggestions came from my colleagues to provide a template of what the answers should look like.
My suggestion is that also meanwhile when you are trying to look at a measuring or a weighing criteria, you are trying to induce probably in your mind implicitly some behavior, some desirable outcomes that you would like to see from those SDOs.
So at least if you can start with the process of what you'd like and through the weighing of the answers, then you'd be able to induce, hopefully, if that is your intention, those changes or those behaviors or those inclinations and make it explicit --
MR. RUBIN: Perhaps I don't fully understand the process, but I understand surveying the SDOs to learn where they are and to profile them and to, in some way, both qualify and quantify as best one can what they have and what they have to offer.
Perhaps what I'm missing is the other half of the equation which is understanding what the needs are both among the vendor and the provider community for standards in the first place. So let's hypothesize for a moment just to take an extreme case that there's a standard development organization out there that's developing a standard that nobody wants, that nobody needs, and that nobody cares about.
Not that that's literally the case, but just imagine that for a moment. What would be the point, then, of including that standard, no less recommending it, as a PMRI-based standard, a recommended standard no less a required standard if it should come to that.
So I'm not fully in tune with what the process is for soliciting from the constituency of folks that would be subject to these standards and that's primarily vendors who provide the applications and provider organizations, healthcare delivery organizations that use these applications and systems to get their work done.
MR. BLAIR: Okay. Question with respect to that?
MR. RUBIN: Please.
MR. BLAIR: Okay. The focus or the question on market acceptance, we were hoping that that would be a way to identify those standards that vendors and users find valuable. Do you feel like that is not a sufficient thing for us to rely on?
MR. RUBIN: I think it may be necessary, but not sufficient in the following way. If you were to ask a vendor of soap or some kind of product how well is their product doing in the industry, they might very well tell you, "Oh, everybody loves our soap and everybody uses it." And that's not necessarily a direct or accurate indicator of whether, in fact, their product is accepted in the market or the industry.
And if I wanted to really understand how well that soap was doing, I would want to go to the consumer and say, "Do you use this product? Does it make you clean? Do you like it?" and so on and so forth. So I think it's a necessary step, but I don't think it's sufficient to characterize what's going on.
MR. BLAIR: Good point.
DR. COHN: Robert, I actually do want to respond to you a little bit also and I actually agree with what you're saying and you will observe that tomorrow we actually have representatives from provider groups and some vendors. You'll also represent some vendors to provide some input.
And I personally do think that the one piece that Jeff sort of left out was I think as we begin to identify these things, hearing more from the users, make sure that indeed these things were valuable and they didn't have anything else that they needed.
Now, we are between a rock and a hard place here though as I think Clem indicated earlier on. We're not out asking standards development organizations in this activity to go out and develop standards from scratch. What we're trying to do is identify standards that already have some road testing that maybe need a little push otherwise. So we just can't ask people to come in and blue sky it. What standards would you like in the next 10 years? That's probably not the right question to ask. So it's a delicate balance.
MR. RUBIN: I wasn't suggesting that either, but I was still coming back to the space. A lot of things can be reflected as messages. So the question isn't whether it's about messaging, but what those messages are about and as you try to prioritize that you may find that there are things that aren't on the radar screen right now for which standards exist or are lower on the radar screen that might want to be higher. That was my only point.
MR. BLAIR: That's a good point.
Clem, did you want to comment?
DR. MC DONALD: A couple of comments. One of them is, there was a survey done two years ago or 18 months ago much bigger than this one. And, in fact, at least independently looking at it, it seemed like they didn't overstate widely their penetration. Now, they may this time around because it's really getting serious.
(Laughter.)
So the goal wasn't to try to do a huge survey and learn everything about it, trying to change the industry. It wasn't to go out and induce them to be better guys and better citizens. But I guess the other side of this is, do you have a suggestion of a practical way to draw that information independently?
There's a tough problem there too which kinds of providers you go to. They don't answer surveys. Everybody's busy. If you have a pragmatic way to suggest doing that, I think we'd like to hear that.
MR. RUBIN: I don't know that I have a pragmatic way. I've never tried to solve this particular problem, but it seems to me that there might be two things that could come together. One is, you certainly have access to the participant list of these standards organizations. By that I mean by organization not necessarily individual. So you can see that Mass General or Partners of Kesson HBOC, you see who's involved with different activities.
DR. MC DONALD: So you suggest we ask for that?
MR. RUBIN: So that's step one. Step two is, how do you get the response back, right? And I think that the prominence of a national committee carries some clout with most people, self included, and I think that if these requests were directed and were succinct enough that they were directed to the CTO or the CIO or somebody in that role, even the CEO of these firms, I think you'd find that they got answered.
DR. MC DONALD: Are you also suggesting that we ask should ask for those lists, their membership lists as part of this solicitation?
MR. RUBIN: Actually, that's not a bad idea. Generally, I thought it was publicly available anyway. You can go to the websites and see at least at the organizational level who is participating. That's not a bad idea to get membership lists if they'll provide it.
MR. BLAIR: But I thought that you were taking it to the next step to say that once we got those lists, we'd use the list to ask the users whether they're satisfied with the standards.
MR. RUBIN: That's exactly what I'm saying. I think that if you target it to the right level of the organization at executive level and it had the credibility of coming from a national committee as opposed to, say, some vendor marketing survey or some magazine or something like that, I think you'd find a pretty high response rate.
DR. MC DONALD: Will you take it as information if one group sent you a list of 2,000 and another one sent you six people?
MR. RUBIN: Say that again.
DR. MC DONALD: What if the membership lists vary greatly in size, would that have an influence?
MR. RUBIN: That goes back to what I was saying before. I think you have to quantify not only the size of the membership, but who the members are. If they're preeminent members, I would take that very seriously.
MR. SELIGER: If I could respond to that. One of the concerns I would have to that approach is that larger organizations that have the bandwidth, they don't put all their bets on one horse. So I'm certainly aware of organizations that are supporting multiple standards organizations and they're going to ride whichever standard they think is going to get them there.
So, in the meantime, let's support as many standards as we have the bandwidth to support and then as the cream rises to the top, that's what we're going to jump on. So I would have some concern going solely based on membership and you reach CIOs, that might be a concern in their response. They may not know yet which standard is their preferred.
DR. COHN: Well, I think if they don't know, then that's valuable information though. And as one who represents a relatively large healthcare organization, Kaiser-Permanente, I can't think of systems that we're buying that we support three or four standards in the implementation.
You have to set upon one set of standards to implement in systems generally, but having said that, I don't think we're looking at the list of names to know who's on the standards group and more that we begin to use them to help us with the survey. At least, that's what I thought I was hearing. So we might survey the larger lists of the full survey not just an HL7 member, are you using HL7 standards? What are you using?
DR. MC DONALD: We basically put out a straw list of potential subject matters and we heard today some different subject matters bubble up and one of the things we could ask the standards organization is which subset of their stuff do they think is really the most right?
That would actually induce them not to say everything and see what really comes out. And that gives an opportunity for some of these other ones which maybe you weren't thinking of that might really be appropriate to be on the list.
DR. COHN: Kepa, before we move on to Mike, do you have any questions?
DR. ZUBELDIA: No, I think you've covered everything.
DR. COHN: Okay. Michael and then maybe we'll wrap up the session.
DR. COHN: I'm sorry. You want to go ahead, Ken?
MR. SELIGER: There's just one point I wanted to make which is and I think I've said it a couple of times, but I'd like to reinforce it. I like the idea of understanding where the standards are on the radar screen. But right now, there isn't a terminology, to you use that word or misuse that word, for describing what's on the radar screen.
I think one of the things that's important for us to do an apples-to-apples comparison of what these standards are that's coming in is we need to put a stake in the sand and say, at least for the purposes of this survey, this is going to be terminology by which we can understand the responses of the questionnaire.
And I think there are a couple of spots where that's been done and the reason I refer to that ISO standard, the reference model for open distributed processing, is that it identifies viewpoints from which those standards can be compared. Now, I'm not saying that viewpoints identified in our -- are the ones that need to be used, but that notion of identifying a particular point of view and having standards groups respond with respect to a point of view, I think really adds value because it says, "Okay. I'm standing here and from this point of view, this is how the standard plays."
And I think having some sort of objective metrics is really required for you to take all this disparate input from different standards groups each doing their own thing, and to understand and piece them together in a way that makes sense.
MR. BLAIR: Will you send that to us or a copy of it?
MR. SELIGER: Sure.
DR. COHN: Mike, do you want to take the last question here of comment?
DR. ROZEN: I want to say that the good news and bad news is we're not as smart as we look, but we're also not as dumb as we look either. We're not about putting out a standard and saying this is the top of the heap, the one that's at the top of the hill without coming back and consulting with the public.
We conduct our business through open public processes and we have an open meeting here and following a survey of publication of results, people like you are going to look at it and say, "I don't believe it." And you may write in letters. You may say, "You're having hearings. I want to come and testify."
That's how we get to be smarter than we really are is that we have people share their brains with us and they tell us, "I wouldn't use this standard for the following reason, but I would consider this standard over here." And a process of getting public opinion and reaching some consensus on the national committee allows us to give pretty good advice to the Secretary.
DR. COHN: And now your final comment?
DR. MC DONALD: Well, this is going to be probably a dumb comment. Get used to them.
DR. COHN: Don't flush anything.
DR. MC DONALD: This market is not such a complicated market. It's a little bit like the market for database management systems maybe. You know if you wanted to stack the market, you could write it down with about five fingers at least, maybe a couple more. It's just that there aren't gazillions of these things out there. There are only a couple of very large ones.
So we're stuck with that reality and I don't know if everyone thinks that the reality, but it really is a pretty small number of players and there are couple of them at the edges that are going to have duke it out about things, but there aren't twenty of them.
DR. COHN: I think with that final comment I actually want to thank the panel. It's been a wonderful afternoon panel and I want to thank you and I'm sure all the rest of these subcommittee members agree. I think that what we are going to do is to take a 10-minute break and then we'll sort of be talking here.
Obviously, I want to excuse you, but it continues to be an open hearing. And we're just sort of talk about what we've learned today, probably talk about a couple of other issues in the remaining time, but let's take a 10-minute break.
Thank you.
Agenda Item: Review of Testimony about Elements of the Proposed Process
DR. COHN: I guess we have about an hour to talk and sort of see where we are. I thought that maybe we'd let Jim talk for just a couple of minutes about something Jeff requested, just talk a little bit about where the rest of the PMRI recommendations are. It may not be a long conversation is my understanding. Why don't start by talking about that. We can talk a little bit about where we are.
Kepa, you can hear us, right?
DR. ZUBELDIA: Yes, yes I can.
DR. COHN: Okay. Talk a little bit about where we are with this document and the next step. I mean the document we're doing and then we'll talk a little bit about meeting scheduling for the full subcommittee between now and June.
And, Kepa, you did receive an e-mail from me about that.
With that, why don't we --
MR. SCANLON: Actually, let me go back even further and start with a report on where things are with the other HIPAA standards as well. Let me start there.
As you remember in terms of standards for administrative simplification as required by HIPAA, a final rule for the transaction standards and code sets was published last October and that is continuing along and with implementation dates coming up, two-year implementation and compliance.
Privacy, as you know, a final rule was published. The effective date was moved back to April 14th, this coming April 14th and HHS has now opened up comments. We are receiving comments on the privacy rule until March 30th, the end of this month.
At that time, the Secretary and others will look at what may be necessary to resolve some of the issues that have come up with the final privacy reg as well. So that's now in the open for comment status. We have in the works three final rules that we hope to be able to publish this year, later this year.
The first deals with the national provider identifier and system. The second deals with the employer identifier number. Again, these were two of the unique identifiers that were required under HIPAA and the third deals with security standards.
It's accurate to say that there is work underway with an HHS on final versions on all three of these. Again, I think we'll have to see ultimately what happens with the privacy rule because that will probably influence what ultimately happens with the security rule as well.
I think there's a desire to have them at least reinforce and support each other and certainly not to have conflicting requirements. So whatever happens with privacy will clearly have an impact on what happens with the security standard rule as well.
Then there are two new proposed rules dealing with the proposed standards that are under development here within HHS as well. The first, as you know, deals with claims attachments and this is actually circulating as a draft at any rate within HHS. The final proposed rule under development deals with a unique identifier for health plans and payers and work is underway with that as well.
So, again, the plan is to have three finals, three final rules relating to those first three that I talked about later this year. But, again, I think we just have to watch to see what the interaction might be with privacy and some of the others and hopefully we'll have a clearer picture of privacy by the end of the month or shortly thereafter as well.
Let me talk a little bit now about the committee's patient medical record information recommendations which, I guess, were made this past summer to HHS. Again, we're suffering somewhat from a transition where we don't have all the new leaders or agency heads in place with an HHS.
But at any rate, the recommendations, you'll recall, were presented to the data council and circulated. These are the ten recommendations relating to the PMRI. Some of them were quite specific and detailed. They were directed at specific agencies and some were broad recommendations directed at specific agencies. Others were very specific kinds of recommendations that an agency should undertake working on this or that as well.
We originally circulated it to all of our data council members and we asked them to identify, number one, to kind of give us a general reaction to the recommendations that they see opportunities, that they see issues and so on. We
also asked them to describe the major activities that their agency was undertaking to support any of the recommendations both the ten overall recommendations and the specific details.
And then we asked them to identify any recommendations that they thought HHS collectively might take in the future to support the general direction of the PMRI. It took a while, but we heard from pretty much all of the agencies the first go 'round and it's fair to say, and I think I could probably share this with the Committee a little later, an actual written document.
It's fair to say that there are a lot of very worthwhile specific projects that agencies have undertaken and they range from just about every one of our agencies from HCFA to NLM to NCHS to CDC to ARC where there really is work underway to support at least the thrust of the recommendations, some of the very specific recommendations.
And, in addition, there were a number of ideas for where HHS might move more collectively. And then we pulled these all together, my office did. We brought them to the data council's data standards committee which is pretty much our expertise, our focal point for expertise on data standards and probably on the PMRI as well and we discussed this at one of the meetings of the data standards committee and we really talked about where do we want to go next and within HHS, what we want to do next.
I think the first reaction was that we wanted to refresh and update the things that the agency's had reported. So that project process is underway now. We've asked our agencies to look at what they'd reported earlier in the light of current situations and to tell us what they're doing, progress on what they had been doing, and again, to tell us what they might see as future work.
So I think what we'll see probably, I'm anticipating is probably some additional projects and maybe some further progress on the projects that they reported previously. On the broader recommendations, again, I think it's just the transition period creates more of a, I wouldn't say a problem, but more of an uncertainty for everyone.
Obviously HHS and I think this was the reaction to the first set of recommendations. HHS can't commit to open-ended adoption of an open-ended regulation standard for regulation obviously. In fact, even when it's not open-ended, you see what a difficult time the regulatory process is.
So obviously HHS can't say that HHS would or wouldn't adopt some recommended standard down the line. I think we just have to see what the specific PMRI standard might be and what the appropriate vehicle for implementation might be. It may or may not be a regulation. The regulatory pathway takes you down a difficult road as you all know.
There may be other ways to move certain things forward. Certain things may not be ready for regulatory frameworks or may even be better suited to some other approaches like use in our programs, use in pilot studies, a little more orientated. There are a number of other steps that one can take to move such a possible standard along than necessarily to mandate it which literally means, as you all know by now, quite aside from the voluntary ANSI and other standards process, this literally means that we're going to make it the equivalent of United States law, that everyone will use this and if you don't use it, you'll get fined or you'll even go to jail.
Once something is to be elevated to that level, obviously, you get into this whole new process of requirements and regulatory and administrative procedures and so on. And there may be a number of things that the Committee may want to do that don't necessarily get into that realm and certainly are not ready for that realm.
So at any rate, I think, in terms of the -- if I can do some triage in terms of the recommendations in the PMRI set, those that were specific and, in essence, said to go and do good work and specifically do good work in this area, I think many of those are underway and I think certainly by the next full committee meeting of the NCVHS, I think we'll have this report updated and I think we can tell you where all those stand. And those are not controversial. Those are basically things that I think largely consensus exists that these are the areas to head in.
Recommendations relating to the criteria to be employed in regulatory actions. Obviously, I don't think HHS could say yes or no. It just depends on what the specific standard is, what the specific proposed regulation is and then it's evaluated in that context.
In terms of process, I think we have agreed to have our data standards committee serve as the focal point for initial evaluation and referral for anything along these lines that don't deal with the specific agency. I think the Committee has certainly agreed to do that. Again, we'll just have to see as we move along.
I think many of the comments that we did receive and the overall next steps, all of the standards begin to relate to each other and this is both good and bad. This was discussed here today. To the extent that one gets bogged down, it affects one of the others.
I think clearly there was a concern about how far one wants to proceed and project in the PMRI area until the privacy framework is a bit clearer. I think, again, in terms of the PMRI recommendations, those that were quite specific, even those that reflected a consensus in terms of supported work in PMRI progress, I think there is a lot of progress to report and I'll try to have a report ready at least for the next NCVHS meeting if not for the subcommittee meeting.
Those dealing with policy and potential regulation I think we just have to -- there's very uncertainty at this moment. I think things have to start falling into place before any commitment can be made there for obvious reasons and I think all we can do here is monitor the situation as we move along. And we'll see what the new leadership may bring as well in terms of agency heads and a bit clearer picture of where people want to go on policies and budgets and so on.
DR. COHN: Before I forget, since you did the overall review, did the annual report actually go to the Secretary?
MR. SCANLON: No, everything is done actually except for a sentence or two on the privacy area. I guess that was to come from the privacy subcommittee. Maybe we'd better remind the ---
DR. COHN: This is for the annual report?
MR. SCANLON: The report to HIPAA, the annual report to Congress.
MR. BLAIR: I just want to add for the other folks. I think Simon is referring to the annual report on the status of HIPAA. I didn't want to make a different comment. I was just trying to clarify for Kepa and other folks that you're talking about our subcommittee's work on the status of HIPAA implementation.
MR. SCANLON: I think we pretty much finished that. We and approval from the full committee at the February meeting to take the remaining changes, add a sentence or two relating to privacy, from the privacy subcommittee and then I think once more through the executive committee and then a final one. Okay. Maybe I should check with privacy to see if they have the language they want to send.
DR. COHN: I just need the timing issue. It might be useful to have it earlier rather than later.
Clem, did you have a question?
DR. MC DONALD: In terms of today's testimony and where we go next, are we --
DR. COHN: Yes, we're just finishing this off and that will be the next item.
DR. MC DONALD: Maybe in terms again of what you were saying about what could be done, could we talk about assuming that this won't be a formal regulation with the force of teeth and death and all those kind of things -- maybe I'm wrong. Maybe it will be.
MR. SCANLON: We don't know.
DR. MC DONALD: There are a series of other positive things one can do outside of the regulations I think, such as saying government agencies would do such and such. Is that true without being a regulation?
MR. SCANLON: Well, it might end up being a regulation for federal programs if, for example, you said that we recommend that HIPAA, the Medicare program, for example used this or that or something else or that ARC in its research grants made this a high priority.
It depends on the nature, Clem, of the recommendation and the specific action, but I think we would want to keep open the entire panel for ways to move some of these forward. Some of these would require regulation though not necessarily a HIPAA-type regulation. It would say, "Those of you who receive our grants or for the Medicare program", if that were the direction.
DR. FITZMAURICE: "For those of you who are reporting certain kinds of data, we want you to use these standards." You might have to put a regulation to serve as a notice to the public, a government requirement.
MR. SCANLON: Yeah, there are requirements for information collections and other requirements just as there were for HIPAA, but there are others that are more at the discretion of the agency. There are recommendations one could make to CDC, for example, for the inclusion of certain standards in the development of the National Surveillance System or in specific surveillance. So there's an entire range of --
DR. MC DONALD: I just want to kind of understand the range. If it's just an NCVHS recommendation, that's not the same as if it's a data council recommendation and I don't know what the leap is between the two.
MR. SCANLON: No. If the NCVHS makes a recommendation to the Secretary, then the Secretary and the apparatus within NCVHS would look at it, data council would look at it and make a recommendation to the Secretary. But I think you're considering here everything from whole conferences and workshops, hold an annual meeting to discuss where we are with that to supporting research and development, supporting evaluation to supporting certain kinds of, to the consideration and inclusion of standards and some of our own systems anyway, to the more formal, "You must do this," through regulations which the HIPAA model ultimately was.
And I think you just may want to keep open all of those possibilities and, actually, there's a fair amount of time as it turns out, as the Committee is thinking about what next steps are appropriate, there may two or three parallel areas and some will be clearer to move on.
DR. MC DONALD: We will presumably come up with some kind of recommendations, at least tentative ones, in the next eight months and then get to some formality in the next twelve months roughly. I think we, at least, ought to be pondering what are the upside and downsides.
The downside of having and absolute regulation is the resistance and the impossibility of look at all the places. Maybe it's not possible. It would be the downside of doing nothing, still like we are now. We don't accelerate anything.
MR. SCANLON: Again, there may be actions you would want to recommend. Well, eight months from now I hope the picture would be a little clearer, but there may be recommendations, Clem, that the NCVHS would want to pursue on a whatever it did on a formal, mandatory type standard.
There might be other recommendations that are more of a R&D kind of an effort, an evaluative effort, a specific program oriented kind of things to get some familiarity and some use and some experience in some of the standards. And those might be the kinds of things.
On the other hand, the Committee may conclude after hearing from everyone that there are several PMRI-type standards that really would make a big difference in moving forward and the best framework was something like HIPAA or certainly some way that the department could use it.
DR. MC DONALD: Well, if it has to be the mild regulation toward your own agencies, what does that entail in terms of the processing and the political forces and all the rest? What is that like? I know what it's like for the other.
MR. SCANLON: Depending on what it is, it could be just as difficult depending on whether it's mandatory or not. Again, standards proceed at the pace of the slowest.
DR. CIMINO: I think that this discussion, I appreciate it because I think we've all mulled about what exactly -- we're not talking about a hammer. We're talking about a variety of tools, but when we intellectually look at the standards, we may be able to rather than be at a high level of theoretic discussion, may get to be a little more practical. At least I hope. That's my hope on this one. Otherwise, it's going to get very confusing six months from now. Without trying to hold it off, I think it becomes unnoble.
Bill Yasnoff?
DR. YASNOFF: Yeah, I wanted to ask about some of these specific programmatic things that we did recommend. I believe we recommended increased research in this area for example, since research funding. Is anything happening with that or what's the path for that?
MR. SCANLON: Well, those are budget decisions for the most part and I think in what was reported, some of the agencies did say they were planning to do this. Another reason when we first circulated the recommendations, it was just at the time when budgets for this year were unknown. So obviously people were reluctant to say we could or can't.
The second round, Bill, people now know what their budgets are for this and they kind of have a picture of what 'O2 will be. So, I'm hoping we'll get a clearer picture now of what the agencies can support.
DR. YASNOFF: I guess what I'm wondering is, is there any opportunity for the Secretary to recommend increased funding in this area in the next round?
MR. SCANLON: It would have to be the FY '02 budget. We're now in the FY '01 budget which is done basically. This year '02, the broad outlines were sent to the Congress by the President a month ago and before long we'll be planning the FY '03 budget. Whatever will be done, Bill, will be within the context of what we already have. If it's a longer term, something that could be two or three years away, then it could be factored into the FY '03 planning.
DR. COHN: Shall we now begin to move into the discussion of today and making sure that we know where we are based on all the discussion.
Jeff, do you want to lead?
MR. BLAIR: Clem, we're going to lose you after today. So could I turn to you first and really want to get your thoughts with respect to what did we learn from the panelists this morning and this afternoon you feel is really important for the subcommittee to retain as we go forward.
DR. MC DONALD: I'm not sure I can distill it that well and it depends on what you do with filtering. There is a number of issues that arose that said we really wanted to do something else than what you want to do. We want to influence the standards groups, we want to learn things that we could use for other purposes.
So I don't know whether that's something we're influenced by where we started out saying our goal is to make some PICS and we wanted information to make PICS. Our goal isn't to be missionaries and change their behavior at this stage.
I don't know whether we take that into account and say, well, let's change our goal and try to change the world or do we want to go forward where we were and see in that context what they said? I need some help from the Committee.
MR. BLAIR: Well, then let me rephrase the question in terms of, we want to make sure that we have your feelings and opinions as to is there anything that you heard in particular today that you felt like is right on the money, something that we really need to make sure we don't lose sight of?
DR. MC DONALD: The idea of trying to get to real truth is always good, but it's not necessarily easy. The idea of actually surveying some of the users, but mechanically, it might really be very difficult. Some of these groups have very large memberships and the process we pick to choose who to survey might have as much influence as, and I've actually from the first round as I recall in reading over the judgments of the standards activities, it didn't seem like they were egregiously exaggerating, but I don't know if I remember it.
Anyone else remember reading over the original reports?
MR. BLAIR: I was very vague in terms of how much it had been implemented and all of that, but I know what you're saying. There were certainly not errors. It was just a lot of times they didn't know.
Clem, I guess I'm sort of talking back and forth with you right now. I think what I heard and I'm remembering perhaps because it was our last session was I heard, yes, we could do a survey and we have to think about that one, but certainly I think we need to be careful as we move forward and make sure to get industry input from what we consider to be credible industry sources and that just is not the people who are involved in SDOs as we move forward to sort of validate that we have the right areas, the standards are important standards, that they think that they're ready for prime time, etcetera, etcetera. And think that yours was coming vis-s-vis due to a survey to get that information or do we do something else.
DR. MC DONALD: If I had my druthers, they would do a survey if we thought we could do it easily because we are NCVHS and somebody should pay attention to the letterhead if we send it out to them. And that would be new information of a kind that's different. It's not so dependent on who was happen to invite to the talk and how they're feeling that day.
So the question is really what sampling could you really reasonably do and whose list would you sample and how would you sample it, American Hospital Association, this or that and then how do you get the right, from a health HMO or health association? Maybe there are a couple of associations and we just do a random sample of 50 institutions or something, but I don't if we have any mechanism, do we have any tool, do we have staff that can do that?
DR. COHN: Jeff is raising his hand up and I'd like to hear Mike Fitzmaurice talk since he's part of our support here.
DR. FITZMAURICE: Is that why you like to hear me talk? What I heard is we put out the criteria. Oh, you want to hear Jeff talk first? Excuse me. Excuse me.
MR. BLAIR: I know that they made suggestions in this afternoon's panel and in addition to getting feedback from SDOs in terms of what their capabilities might be relative to the criteria we're setting up, we also wind up getting feedback from users.
My thought --I harken back to a comment that you made, Clem, several months ago -- is let's try to keep it as simple as we can. So I'm going to give you my opinion now. My reaction is I think we're going the extra mile with the process we have in place so that all SDOs will know that they are being fairly considered with criteria that it openly considered, that there's not a prejudice, not a bias. We're doing this very deliberately.
I do think it's valid for there to be an additional input to get user perspectives on this and I think htat to try to do that with minimal effort and not doing a lot of extra time, my thought is that after we have gotten the input from the SDOs on what their capabilities are and we pull that into some type of digestible, comparative matrix or summary, that we take that and we bring in for testimony maybe in the September time frame, six or eight or ten selected representatives of the provided community and we run it by them in terms of the data that we've gathered and we ask their reactions to it.
And I think we won't lose a lot of time. It flows into our process pretty well. It's not a lot of extra effort to expense, but we would get an informed reaction from the providers because they'd have the most recent data and I think that might be an expeditious way to handle it.
DR. MC DONALD: You're talking about institutions as providers, not persons?
MR. BLAIR: Well, I think it would be a mixture and I said six or eight or ten and I think maybe a couple of them would be large managed-care organizations, maybe a few others might be some hospitals. Maybe two or three or four might be group practices and some other folks might suggest something that we've left out, maybe a long-term care institution. I don't know. Some attempt at diversity.
DR. MC DONALD: That's what I mean. You mean organization caregivers, not me as physician because I probably don't know.
MR. BLAIR: Yes. Although probably physicians might represent some of those institutions. Do you think that that might work?
DR. MC DONALD: It's just that the physician at the individual physician/nurse level, they are not likely to have awareness of this stuff.
DR. COHN: At the AMA level.
DR. MC DONALD: Yeah. You could find a representative of the clinician, the physician.
DR. COHN: Mike, do you have a comment?
DR. FITZMAURICE: Couple of comments. One, on the criteria I heard that different testifiers and different priorities as to what was important to them, but all of them felt that the criteria were good. The most dominant priority I heard was whatever you choose, focus on interoperability and comparability.
On the example, the trial set of standards that we proposed, I didn't hear anybody say that's a bad one, that's a bad one. Well, I heard one. One testifier said, "I don't think this is a PMRI standard." But when encouraged to express it differently, she said, well, she probably wouldn't disagree. She probably would agree that if you combine it with information that comes back to the physician, say, from the pharmacist that there are patient medical record information aspects to it and they probably wouldn't want to give up that turf. They would want to include that in their standard.
With regard to the SDO standards, again, nobody said this particular question is bad. All of them seem to be good, maybe not equally good, but good and the comments we got were additions. In addition to this, I'd like a further explanation of this or I'd like to see these set of questions asked.
I think that's telling because questionnaires can be burdensome particularly if you're asking questions that will cause them to probe into information they don't have on their desktop. I don't want to answer that. We didn't get any comments like that.
It probably reflects the fact that it's been done before and we found the SDOs responsive and so people think the SDOs would be responsive again to a questionnaire like this. With regard to the other questions, we heard again what a different interest ranging from we ought to have a single standard whereby we can communicate security and privacy policies out to all of our systems within an enterprise to a bunch of other practices including modeling and architecture that may or may not be part of our mandate.
But if you look at patient medical record information standards, we have to decide where most productive and modeling is not often most productive, but if you can find a simple model that you can put out there and let others build off of it, that's fine, but I haven't found the simple model to do that yet.
Those are just some of the things that I've heard. I heard also about economics and the role of the government. When the government chooses a standard, you can create a monopoly. I heard it last year from Bill Yasnoff. I heard it a couple of times on slides here.
So what is the role of the government in this? Right now, our role is to speed it up, to push them, to prod them, but does another role deserve consideration? The role of deferring monopoly status on a given standard or buying up that standard to making it freely available to everyone.
Those are some possible roles of the government that we may have to consider since we're becoming a learned body, a learned policy advisory board to the Secretary on issues just like that. Who else knows as much about it as the national committee?
DR. MC DONALD: I really think that that was misconnected to the subject matter. I think that that was really directed at the vocabulary standard situation not to the message standard situation. We can't buy up X12 and there's not a cost issue in terms of the monopoly.
MR. SCANLON: And we get it US. This is not Sweden.
DR. FITZMAURICE: On the other hand, it's not out of the realm of possibility that when determining a standard as a public good and find a fair market price for buying it up and maintaining it because it's for the good of all.
DR. MC DONALD: But then, well, we're not talking about big bucks with these standards.
DR. FITZMAURICE: And I'm also not talking about the government taking over and making it.
DR. MC DONALD: We're not worth that much.
DR. FITZMAURICE: We may find a way to sponsor or subsidize a standard to make it available more freely to everyone.
DR. MC DONALD: That's something. That's a spend down. There's a precedent for that X12 was given a relatively modest fee to make it publicly available without the usual small fee.
MR. SCANLON: I think HIPAA's criteria for this was HIPAA understood this even though not in the depth that we're now beginning to understand it, but the criterion for HIPAA for a low-cost distribution mechanism, not free and not a monopoly necessarily, but to use the existing standards and somehow make them not have cost be a barrier and that for some of these, that works pretty well. For others, it's difficult to see how that's going to be resolved.
DR. FITZMAURICE: I think my point is just that we can't avoid the economics of this and by choosing a standard, it may the same as conferring a monopoly and there are other ways of doing it and may operate just as well.
DR. COHN: Well, I guess to follow up on that one. I think we're all getting little lights going on in our head at different points because there was a lot of information and I presume we'll be distilling that and coming up with the points.
But a number of the testifiers did comment that the cost here is not the cost of the standard, it's the cost of the implementation of the standard and that that was really the thing. It was the big deal. It wasn't whether it cost $10 or $100 to get a copy of the standard on the Web or even $1000 to buy it in a silver case or whatever.
But we may want to ask that. I guess I also heard that there were some people who thought that the standards were a little bit different than we had described or a little bit more expansive or whatever and I'm fine with that. I think we just need to go through and look at the testimony and perhaps, have the opportunity just to ask the wider question. Let's ask the wider question.
DR. FITZMAURICE: I agree with you, Simon, on the cost of the standard. I think one of the points that was brought up was that when you get good experts involved, you may not take a lot of people to make a really good and industry accepted standard, but you can't always get the best experts to come into a standard development organization and spend the time that it takes to get the completion of the standard. That may be a cost of developing a good standard too.
DR. COHN: Yeah I heard that, but I don't know that that's on point of what I was referring to specifically which is that do these implementations in a place, and that's where it costs the money.
DR. MC DONALD: Just to clarify again: Is what part of -- we set up a scope and one of the scopes was low hanging fruit. So there's the first question to maybe a few other things are low hanging fruit. But, will we now say, maybe we should tackle the whole shootin' match? Are we thinking of that or just some more low hanging fruit?
DR. COHN: No, I don't think so.
DR. MC DONALD: Okay.
DR. COHN: But what I'm saying is that some people, for example, they were talking about orders and I think we had identified two or three orders that they were saying expand the description of orders a little bit. For example, that's what I mean. I'm not saying every single HL7 standard in exquisite detail necessarily though I think if they have ones that we don't know about that are really ready --
DR. MC DONALD: What you're saying is we should look at the testimony to see how we might adjust our scope, but we're not going to give up on the low hanging fruit theory.
DR. COHN: Exactly. At least that's my feeling.
DR. MC DONALD: So we can get something done in a year and we then we get some more done after that.
DR. COHN: That's right.
Jeff?
MR. BLAIR: I was really pleased with many of the good suggestions for things we could do to add and clarify what we had. There are some things where you start to get diminishing returns however as you begin to add questions and one of the thoughts that I had was, I think it's a very correct statement that most of the implementation cost isn't the licensing or the maintenance cost.
It is the implementation and three or four years ago when we did the other massive survey that we don't really want to repeat, we did have that question in there and people really couldn't answer it and they didn't really want to answer because it starts to get into an area where they know that there's heavy costs for implementation and they feel it would wind up revealing their standard in a manner that's disadvantages to them.
If the subcommittee wishes us to go ahead and add that question, I don't have any problem in adding to it. I just question whether or not we're going to get very useful information on that particular type of question.
DR. COHN: Jeff, you're probably right. To me, trying to figure out how you would discuss the cost of implementation in the standard versus the system that implements that standard, I don't know how you would. I mean that would be really tough.
DR. MC DONALD: Versus the alternatives. If you're doing a standard just for itself versus you're going to hand them the data otherwise. It's tough.
DR. COHN: How are you doing the metric?
MR. BLAIR: It doesn't hurt to ask it and we'll see if we get some useful information.
DR. MC DONALD: My only suggestion about adding the questions is that we got in a lot of suggestions and there are different orthoganly different motives. Some of them were, we really want to get a clearer idea which one to pick. Some of them were, we want to change the behaviors. I mean literally there are some explicit and different ones and if we're going to do this for the original purpose, we have to be careful about expanding the directions of the questions.
MR. BLAIR: If you wind up trying to please everybody, you could double the size of this questionnaire. I don't think we want to do that. At least in my mind, I think that if we expanded it by 10 percent or 15 percent, that would be maximum that I would feel comfortable expanding it.
And I think that we go through, winnow out all the suggestions, pick the best ones to add, and just wind up accepting that so that at least we're not overwhelming the SDOs when they're going through trying to answer these questions. That would be the balance that I would think of.
Clem, do you feel comfortable with that?
DR. MC DONALD: Let's make it better. Let's not get this to be a three-year project.
MR. BLAIR: Right.
MR. SCANLON: Jeff, how many SDOs would be involved in terms of getting the questionnaire?
MR. BLAIR: Well, for message format standards for the one we did for clinical information standards three years ago, we only had 16. Now, HL7 had about eight of the 16, eight or ten of the 16. Okay?
MR. SCANLON: Um-hmm.
MR. BLAIR: We'll have some more now because the number of standard categories that we listed there is a little broader and HL7 does have more implementable standards now than it did before. The others are pretty much the same. There's a DICOM, there's and IEEE, NCPDP is still there again. So maybe we'll have 20-24.
MR. SCANLON: Probably two dozen or fewer?
MR. BLAIR: I really would think so.
DR. COHN: Now is that standards or standard development organizations?
MR. BLAIR: No, no, no. That's standards. I think Clem's guidance to us was very good and he said look at a particular transaction and have each organization fill it out for the transaction, not for their SDO, but the transaction.
DR. MC DONALD: I don't think there are any SDOs en block.
MR. BLAIR: I'm thinking that we're probably looking at about maybe 24, maybe 20.
DR. COHN: I guess I should just ask as we look at the areas. Do we want to ask a question about patient or consumer information?
MR. BLAIR: That's one where you tell me how you feel. My inclination is that's a one-line item where we could put it out there. I'm not aware that any SDO has come up with a standard for transactions between a personal health record and an institution. I don't have a problem saying that's a valid category and if anybody has a standard, we're willing to look at it.
DR. MC DONALD: In some sense, it's really the same stuff. And the problem is it just gets a lot harder to distribute passwords and control access. That's the big challenge.
DR. COHN: But also, iit'slot of the same stuff, but there's also other stuff. There are actually are things that are probably part of a consumer personal health record. YYou'repart of the NHII stuff.
DR. MC DONALD: Not very deeply. If there is, that wouldn't make it a ddifferentstandard anymore than if I get x-rays and lab and now I get EKG's, it's not a different standard, I just happen to have more data. If I have Encyclopedia Britannica versus, you know.
There's just ggeneralknowledge content is what you might want to say that would be a different critter bbecauseit wouldn't be protected. You don't have to worry about it. So you might ask if there's something about patient information generic that would be something distinct.
MR. SCANLON: There are actually, it's not much in the SDO world, but certainly iinthe public health world, there are efforts to create model and sometimes even standardized health risk appraisals for individuals to use and it's standardized more or less in terms of the content in the questionnaire and the measurement aspects, not so much SDOs.
DR. MC DONALD: But that's getting into codes and all.
MR. SCANLON: Exactly. It's specific measures.
DR. COHN: That reminds me of a question and I'm a little orthagonal here and I apologize, but I was reminded during the CDC testimony that we didn't hear much about this, but there actually is a immunization transaction as I understand. The question is, I see that as a little bit different than asking all the SDOs if they have an immunization transaction, but more this is one where as I understand an implementation guide etcetera, etcetera.
DR. MC DONALD: It's an HL7 standard already.
DR. COHN: That's true, but what I'm saying is --
DR. MC DONALD: You've got to remind them maybe that they may want to submit that.
DR. COHN: Well, that's my question is either CDC or HL7?
DR. MC DONALD: It's sort of an order end results thing, specialized thing.
DR. COHN: It isn't quite. It's something a little different.
DR. MC DONALD: It's a specialization of the order of the drug orders.
DR. COHN: IT's a transfer of the information typically from a local site to an immunization registry, isn't it?
DR. YASNOFF: Or between registries.
DR. COHN: So it's a little different, but I think to consider that that's a mature standard. I'm sure that looking at things with implementation guides.
DR. MC DONALD: I think that pretty low hanging fruit.
DR. COHN: Yeah, I think we ought to not forget about it. So maybe we need to make sure. Are we asking you to make sure about that one?
MR. BLAIR: What do you want me to find out?
DR. MC DONALD: I think just a matter of such as public health immunization just to make sure we pull them out. I think the question is do you have them fill out a questionnaire that somehow addresses about its use. I just bring that up as a category that we hadn't talked about where you go, there is something there.
Go ahead, Jeff, I'm done.
MR. BLAIR: One of the things that I think might be helpful for us to discuss, I feel like in terms of resources, I could cull through the testimony, I could update the questionnaire, I could get it out by e-mail to subcommittee or critiques before we send it out.
I do feel like I really would like to have help when the data comes back because if there are six or eight pages average in terms of the responses and if we have 20 of them, that's a lot of data for a blind guy to sort through and I would hope that somehow we might be able to hire a staff person to assist us in pulling together some type of a matrix or Excel spreadsheet or something like that, whether it might be Margaret Yen or someone else.
And, Michael, would you be able to help us with that?
DR. FITZMAURICE: I could help you to a degree. I'd have to get my own time for resources. I'd have to go to my boss.
MR. BLAIR: Now, Michael, you also indicated that there's -- are there other issues, Michael, with respect to resources and the process that we're about to go through which you think we need to discuss in terms of sending out a survey?
DR. FITZMAURICE: Yes, I'm not sure what the law is on that, but if the national committee is government employees and the government employees are sending out a survey, then there are government rules with regards to sending out a survey. Think in terms of OMB and other clearances that might be necessary.
I just don't know about how a national advisory committee does these sorts of things. It's beyond my scope of experience. I know that if I were to do it as a government person, I'd have to go through the department. I'd go through OMB clearance and that would be it.
DR. COHN: That would be to the SDOs or are you talking about the more widely sent?
DR. FITZMAURICE: If I were to send it beyond ten or more, then it requires survey clearance from OMB.
DR. COHN: We may not have that many SDOs.
MR. BLAIR: I don't think we have only nine SDOs.
DR. COHN: We might make it.
MR. BLAIR: You name them off. We have our little status sheet, but there's HL7, DICOM, OMG, NCDPD, IEEE, and I've got six and I'm starting to wonder. So I don't think, if that's the threshold, we may make it.
DR. COHN: That may make us think hard about doing a wider survey.
MR. SCANLON: A general survey even if it's a sample survey.
DR. COHN: Jeff suggests and I sort of agree with him that maybe doing a hearing might be a better way to get the information.
MR. SCANLON: Give them the questionnaire and ask them to come in and talk about it.
DR. FITZMAURICE: Talk about the paper that they'll drop off and testify.
DR. COHN: People will get the Air Flight Improvement Act.
MR. SCANLON: If I can respond to Jeff's other question. We do have some resources, Jeff, available to the committee for consultants. Now, again, we have to go through the process of getting someone. I think Margaret helped us with my report. In terms of the analytic work, presumably we could get to her. It's just a large enough enterprise that we probably almost want to get someone who could devote a fair amount of time to it rather than try to get someone else.
MR. BLAIR: If I could just make a note in terms of my personal comment is that an individual like Margaret not only had the ability to be able to work quickly and assimilate that information, but she also understood it and that's extremely important in being able to make sure information is properly set within a matrix or spreadsheet.
MR. SCANLON: She was one of the two dozen people in the United States who understood it.
DR. MC DONALD: I was actually going to start to volunteer. Maybe I get some from my office, but there's two things wrong with that. Firstly, I may not have enough time and secondly, it would be best if this was done independently.
DR. COHN: Both of those is true. I do want to spend a minute or two talking about this business of the ssubcommittee but we are sort of at least as of today, straight with what we're ddoingrecognizing we do want to see a revised copy of the questionnaire and I'm sure we'll have other input from tomorrow.
But it's really going to be a question of Jeff and Mike sifting through the ideas that were expressed using some judgment about what makes sense to have in, what makes sense to have out. There is tendency of the subcommittee is to have things be leaner rather than asking everything possible and making this easy on everybody.
Kepa, do you have any comments about this before we move on to subcommittee business?
DR. ZUBELDIA: No.
DR. COHN: You've been very quiet.
DR. MC DONALD: He's a very patient man.
DR. COHN: That's right.
DR. ZUBELDIA: Well, you've got everything covered there.
DR. COHN: I do think we will see some changes to that survey in the process. Now, any final things before I move on to subcommittee activities and all that.
MR. BLAIR: I hope that we can in subsequent hearings still get kind of an industry overview because I think the discussion to day shows us what a peculiar market this really is, exactly what kind of a market it is. I think CVlem was suggesting that it was like the automotive manufacturer's market with may half dozen or fewer that really control things.
DR. MC DONALD: I'm not talking about the market of the software developers or the hospitals. I was talking about the SDOs.
MR. BLAIR: Yes. And it's just not clear that we still don't seem to have an overview of how the market really works and if the market does have failures, what the nature of those failures are. You almost need someone who follows the industry in terms of IT and how the healthcare industry responds to IT issues, how it makes decisions, what it invests in as a backdrop for some of the standards, the next generation of standards I think.
DR. COHN: That's true. I don't know when we'll do that, but I think it's a good idea. Just as one who looks at it from the other side which is obviously someone who buys these things, he has to build at some point. A lot of what we're talking about is not failures in standards. It's more, the fact is, is that you want to have a standard that has a fair amount of credence, that you know is going to be around and supported because you're making major software investments based on it.
You don't want to go five years into an implementation or five years after it's been implemented and suddenly discover that you're going to have to swap out a system or change a major processes because you picked a wrong standard to do X, Y, and Z, I see a lot of what we're doing is providing additional reassurance to the, not the IT industry and not the SDOs, but more the people buying the systems that have these standards in it that they are making the right purchases, that they can rely that this thing will be around and have sort of the full faith and support of the US government behind that this was the right pick.
DR. MC DONALD: Another way to do this, but it probably isn't practical either is to get a hold of, if there's any way to sample our request for proposals from institutions. I know what you're going to see in there. It's going to say we want this thing for this standard and we want that for that standard. I don't know where do they do. Is there a place to intercept those?
MR. SCANLON: Where do RFDs go when they die you mean?
DR. MC DONALD: If every large institution wants to buy an X, they make an RFA or RFP and I don't know where they go where they can grab a hold of a sample of those.
DR. COHN: Go to consulting firms and ask them what the RFDs are.
MR. BLAIR: Clem, my eyes rolled to the back of my head when you said that because when I was with IBM, we would get these RFPs from large clients and customers and they would he massive and they would be big and they would be detailed and you'd look through the whole thing and you'd really question whether or not that massive amount of work both to prepare the RFP and for all the vendors to fill it out, whether that was really getting at helping them solve their problems.
DR. MC DONALD: I know what you mean.,
MR. BLAIR: So I would rather not touch an RFP.
DR. MC DONALD: You could get a real sample.
DR. COHN: But beyond that, typically what you're seeing in that is you're seeing the consultant assisting someone with the RFP and the person who is actually buying the software is hoping to heck the consultant came up with the right standards for whatever.
MR. BLAIR: Maybe we could get at it a different way. Maybe we could wind up hearing directly from consultants that prepare RFPs and just ask them to give us guidance and why and what are their views and opinions on that.
DR. COHN: That's a good idea. You get a sample of a couple of the big firms.
DR. COHN: It's obviously whoever is buying is buying where they're buying, but the vendors are national.
MR. SCANLON: It's like a lot of other markets and you try to see what you should do with anything to move things along.
DR. COHN: Now, let me make a couple of comments about what's happening between now. We've received a communication from people, the SDOs, asking and as you know one of the things we need to do is to meet with the SMOs to understand what they've come to in terms of the data requirements on the revision of the standard which you're all familiar about what's going on right now.
And they've requested rather than meeting with us at the end of April, beginning of May and that was the schedule, May 1st and 2nd schedule that they instead meet with us at the end of May or early June for the session we have scheduled for May 31st-June 2nd.
So with your forbearance, I talked to Karen Trudel earlier today just to make sure there isn't something else we need to be handling at the end of April, beginning of May which is only six weeks from now, not very long. She felt comfortable it would be okay to cancel this.
It was certainly my thought that we should cancel it. I do want to bring it up to all of you to make sure that there isn't some pressing issue that we should be handling at the end of April-early May.
Clem, don't cry.
(Laughter.)
Kepa, are you okay with that too?
DR. ZUBELDIA: Yeah, that's fine.
DR. COHN: Okay. So what we're going to do then is cancel the May 1st and the May 2nd hearing dates and we'll just have one two-day hearing between now and the next NCVHS meeting which would be May 31st and June 1st. The new focus will be receiving the recommendations for the DSMOs about the changes to the standards based on their work over the last couple of months which I understand is going along very well. This is what I'm sensing and hearing.
The question would be whether or not we have time for any consultants to talk to us about clinical standards at that point and their usefulness, what's missing, what's good and what's bad. We'll see how the agenda plays whether we do it then or into the summer or into the fall? Do you have a preference on that? My bet is if we cancel a spring meeting, we'll probably do it in the summer.
DR. MC DONALD: I think it's a very good idea, but I think we should be very targeted. We should say, "We'd like to get data from you." They wouldn't come in with some other opinion. That is, they would talk about that subject not some other subject. And it would give us some sense of distributional numbers. There shouldn't be anything illegal of anything.
DR. COHN: Some people think that's competitive information.
DR. MC DONALD: Well, they could give percents instead of total numbers which tell how many camtreks they had. They could say out of the last "N" percent, whether it's 20 percent, 30 percent or whatever.
DR. COHN: Okay. What I'm also hearing looking past June, I suspect that we're going to have a fall hearing of some sort related to PMRI standards and as you all know, the HIPAA stuff is sort of left in the air a little bit, but there is a lot of things happening, people wanting this, wanting that.
It's really unclear what's going to be happening with time lines. Are they going to be affected or not? Certainly, I think our intent would be to hopefully during the summer or fall we can talk some about the enforcement and compliance for the standards assuming that time lines remain the same.
DR. MC DONALD: Why do we want to talk about that? Why do we have to talk about that? They aren't really in place yet or are they? When will they start being the deadlines being met?
MR. SCANLON: The transactions and code sets and there is a two-year ramp up between last October and the actual compliance date.
Mike, do you remember what it was?
DR. FITZMAURICE: It was over 2002. But we may want to wait until there's a notice of rules on the enforcement because there's an enforcement team that's begun to work on that.
DR. COHN: Usually we do hearings before there's a notice of proposed rule making.
MR. BLAIR: In a sense, maybe we just need to put aside that time in September because although we don't know exactly which topic it may be, there are about three or four topics that are high candidates that go on either time.
DR. COHN: The question will be whether we do something in August or whatever.
DR. MC DONALD: To toss out another one, if we do get privacy settled down, are we going to come back to patient identifiers? It's hard to do all that stuff without it.
DR. FITZMAURICE: The department can't do anything about it.
MR. SCANLON: HHS is still forbidden to spend any of our appropriated funding on that issue. And when the Committee meets, we are spending appropriated funding on that. We'd have to see.
DR. MC DONALD: That's a clear answer.
DR. COHN: I do think that without doing hearings, it may be appropriate at some point to come out with a letter if we think that the privacy and security areas are getting pretty well handled.
DR. MC DONALD: We always said we were going to come back when it was handled.
DR. COHN: As I said, what we will be doing, I think, I think both Clem has problems with dates and Shortliffe has extreme problems with dates. I guess we'll be seeing him a couple of hours tomorrow morning.
What we'll try to do is to query people about some dates for hearings for the next half of the year and I'm going to have think out, Jeff and I will talk about whether we try to do one. Knowing that September and November are NCVHS hearings, full NCVHS meetings. It sort of leaves August and October for possible end of summer or fall hearings. Either we'll do one or both or check people for both periods of time.
Is that comments, questions or otherwise?
DR. MC DONALD: We need some time to discuss, to make proposals, to actually get this done. Are you planning that> So we're going to get back the information when? When might we get back the --
MR. BLAIR: You're back to PMRI now, aren't you?
DR. MC DONALD: I'm back to finishing the job.
MR. BLAIR: Generally, I'm talking off the top of my head. This is not set in concrete, but generally, we were thinking that if we distributed the survey to the SDOs in May, that they probably would get it back sometime in June, maybe the end of June if they needed that much time. We'd analyze it in July/August.
We'd wind up reviewing it as a subcommittee in September. We'd probably, as a result of reviewing the data, we'd probably have some additional questions or concerns that we wanted to clarify with the SDOs on those things. It would probably bring up some new issues that we haven't thought of.
We could get those things addressed in October or November and in November and December, we'd probably start to basically start writing our report with our recommendations and, by the way. I sort of slid over it that way because in my mind, I guess I sort of feel as if the recommendations like many of us have been saying here, are not going to be definitive.
Here's the ones that you will adopt, but they will probably be, in this particular area, these are ones that we thing would be helpful. In other areas, we think that they may be helpful, but you need to wait for the next version.
And another one, there's something else that maybe helpful within a certain context. So I figure that maybe in the November/December time frame, we would be working out what those recommendations are for individual transactions. We'd probably have something to distribute as a draft in January to get critiques on it and then we could submit it and review it, I guess with the full committee in February.
DR. MC DONALD: I think we need some time between then and now to be thinking about this because that's not how I would have thought it would come out. I would say we're taking the low hanging fruit, we're going to set certain criteria and not future versions.
That's back to speculation. We would be talking then about what we're going to consider in our next route and we got to be thinking about what kind of an approach we'd like the government to take with these because it interacts with what we would say.
If we say this is just an informative report what our off the top of our head opinion is, that's one thing. If we're saying that these certain ones should be used by HIPAA healthcare environments, that might be hard, but I think we need to be spending some time on this because I think we're going to get the answers in and we're not going to have a whole lot more questions that we're not going to get good bets on what they are. We're not going to be totally ignorant about what we might be thinking until we get the last answers in.
DR. COHN: August is a good time to think when you're in Washington, DC. It's hot. You can't go outside. So you might as well.
DR. MC DONALD: We've got to think too about these issues because maybe you're right, we'll say something about all of them. Everybody will be happy. We'll say this one is good for this and this will be good in a couple of years. This one everybody loves, but it's not quite right.
DR. CIMINO: I guess my own feeling is once I see the data a little better. I don't know this for a fact, but one could imagine, this is based on the NCPDP testimony earlier that it may that we actually recommend a different approach for certain types of these.
Some of these may be so close to administrative transactions and once again, as you know, the longer I'm in medicine the more confused I get about what's clinical and what administrative. Financial I understand because that's dollars, but there is a lot of administrative and clinical. It just gets really confusing and indeed it's a mature standard.
It meets all the pieces. It isn't saying that everybody in the healthcare sector has to use it, but we might want to go, for example, with something like that that's mature saying that if you're going to do this, do it that way which I think is about as far as we can go with these things.
DR. MC DONALD: I think that's what you would want to do with a lot of them. The question is going to be the couple that have end collisions. Those can be the hard ones. So the NCPDP, they'll collide at the edges. The NCPDP and the prescription writing and HL7 are very overlapped.
MR. BLAIR: That's going to be an interesting issue.
DR. MC DONALD: DICOM and reporting are very overlapped. They'll be a handful of those things and I think what you'd really try to do is to get the standards organizations to come to us with something that said some kind of a way that they take care of that problem for us.
DR. COHN: But, Clem, I actually agree with you. I certainly think that this is an opportunity if there are conflicts between the SDOs, we need to understand it.
DR. MC DONALD: Conflicts is too strong a word, but they will be bumping up at the edges.
DR. COHN: Thank you. Bumping up against each other, but on the other hand, when we were talking about the HL7 standards and I'm looking at Stan Huff who gave his testimony this morning, he's driving a six-year implementation. So that's sort of a slow move forward sort of thing.
DR. MC DONALD: You have to put it in context. We have, in our hospital, 250 million results in HL7 going back seven years. So I don't know what you're really talking about six years in the future, six years in the past. There's a lot of these things that are just out there. They really are flowing and I'm not specifying that particular one.
The point is: If you want to do it at a higher, you can always find another set of steps they can do, but it's not like there ain't anything out there with that. That's what I'm saying. I can give you the counts.
DR. COHN: I was just reflecting on what was described in terms of the process around HL7 and the testimony this morning. I'm hoping that we have something that's a little firmer and a little tighter than six years.
DR. MC DONALD: I'm probably slandering Stan to his face here, but Stan you ought to come to the microphone. If you accept free text, it's very easy since the codes. It depends on what level of absolute you want. As the codes find an accepted life, we'll much more absolute.
DR. COHN: Stan, I apologize for misrepresenting what your comments were.
DR. HUFF: It's not a misrepresentation. I'd just like to further amplify. That kind of time period is the time period in which I think you could mandate, for instance, that all microbiology data, all microbiology data came to CDC in that format. I mean that six-year period of time, that's taking into account the people who aren't even automated now, a whole bunch of other things.
Tomorrow, we could start sending the stream of microbiology data from our institution to the CDC and it would be all Hl7 and it would be good transactions because they're the same transaction we used to put it into our electronic medical record.
To standardize that to the way that it needs to be, what we're lacking right now is that's not standard terminology in those transactions. So Clem could probably provided that too. There are things that you could do much quicker I guess is the bottom line.
We've already got, for instance, a good implementation guide for immunizations. We could start doing that. People are already working on the microbiology one. If HL7 made some definitive statements about use of LOINC codes and lab data, you could do 90 percent of lab without any further fiddling around. So I mean it does take time and I guess the distinction that I would make is that there are things that you could do that are very useful that you could do in a year or six months or something like that.
The six year time frame is when you start talking about mandating it and all data must come in that format from all sources. That takes a long, long time to do and it has huge impact on people's institutions. There are things that have much lower impact that are very useful that you could do much quicker.
MR. BLAIR: Just a comment that if we started through an NPRM process, it would take us six years to put together.
DR. MC DONALD: Stan said what he described in a six year time frame is if we all had perfection in all the ways we knew it including Chris Chute's perfect way. It's going to take a long time. The SCRIPT standard, which is a very good standard, says send free text for the name of the drug or send a code if you have it. Well, that's a lot easier. So it just depends and you could do that on a lot of standards yesterday. I'm not saying that's bad.
DR. COHN: The problem is you don't have a drug terminology code.
DR. MC DONALD: I'm only saying there is a spectrum of expectation as you go further along that spectrum, it's harder.
DR. COHN: I agree with you and it was nice to hear from Stan about the fact your comments about six years didn't apply to all of the standards and that there were obviously are gradations in terms of what recommendations we could make. I had taken your earlier comments to be that should be sort of the game plan for everything.
DR. HUFF: I think we should pick easier things and we can do the easier things faster and there may be some that we couldn't do in twelve years or something. They're too hard.
DR. COHN: That's good clarification.
DR. FITZMAURICE: There is one other part that we hear today and that is that as we're going through this, there are gaps and one part of the report or the next report may be we find these gaps and nobody or not many people are working on it. We want to encourage people to work to fill these gaps. We want to encourage the Secretary to take action to fill the gaps. That could be another part of the report or a follow-up report.
DR. COHN: That's, I think, a different set of data and we've already made a number of points that are missing. I would just warn you that that's a specific topics of hearings or otherwise which we haven't been eliciting so far.
DR. FITZMAURICE: I agree, but we heard today that somebody ought to be doing some GEP(?) analysis and we heard it before and that may be one of the follow-up activities to this report.
DR. MC DONALD: This all comes back that we aren't necessarily synchronizing how we're thinking about this yet. Even now, even though we've been working together for like four years, I think we should schedule some time to think through some scenarios. Just like this.
Totally theoretic, but what would do with this and we realize we've got different world views and we may also need other information or other testimony based on that. If we wait until December to start thinking about what are the sort of things we can deal with, what's the issues, back to June, what tools are there?
MR. BLAIR: Clem, did you think that the plan I was laying out indicated that we would wait until December?
DR. MC DONALD: I thought I heard you start writing the report in December and I didn't hear any time scheduled to be thinking about these variations and what are the concepts, how far we'd go. How we'd lay out. We just now talked about a few of them and we had different ideas and that was informative.
MR. BLAIR: Maybe there's really not the same gap that you perceived. Maybe with the way I phrased it, now I understand why you said what you said. My thought was that in September, we would be receiving a lot of the information from the SDO in a manner where we could analyze it and draw conclusions and my thought is that in September we probably would have to spend a good deal of time as we go through that, winding up, coming to conclusions as what it means.
Some things we'd be able to wind up saying it tells me this, it tells me this, it tells me this, but it doesn't tell me this. We need to get this clarified and we called the SDOs back for hearings in October to get certain other things clarified, but we we've already got maybe 60 or 70 percent of the conclusions in place as a result of hearing, seeing the results of the survey.
So it could well me that a draft of the report could start being done in the October time frame, but my thought was that the real first drafts maybe they would be in November or October or something like that.
DR. MC DONALD: I'm not worried as much about the writing as the thinking. If we start writing without having done some of these discussions, it's going to be slow. Tehre's other issues and we need your help on this. The law does say something about ANSI SDOs. What borderline, when do we do differently and how strongly does it have to be completely? We need to know about that upfront.
MR. BLAIR: Okay. Then let me try to converge with you. In addition to reviewing the material that we have in September, that in September we're also winding up saying, "Okay. Here's the set of conclusions we can make." So we are doing some of that in September.
In October, we're getting clarification from SDOs and then winding up making additional conclusions there. So we're doing it again in October and then maybe we'd wind up if we can meet in November, that we'd take this to the first draft and review the first draft in November.
DR. MC DONALD: The only thing that would make me happier is if it's like in August or sometime. We would actually spend two hours dealing with the legal, whether if it's 2 percent different, does that make it work when it's not an ANSI SDO? We should get some advice from somebody on that?
DR. COHN: I was joking when I mentioned August. I wasn't joking about not being able to go outside.
DR. MC DONALD: Just to dedicate some time because we may shift the questions we asked. If we don't wrestle with some of these issues, I think we have very different views. I think many of us agree that we probably aren't going to come out with this iron clad PMRI like we do for the administrative standards where they're going to go to jail and have $25,000 fines. But what's available that would be an incentive to somebody, to the industry because all government agencies would have to do this with their healthcare data.
DR. COHN: But maybe we'll have things back and have them worked on by August.
DR. MC DONALD: That would be ideal.
DR. COHN: We need to figure out what's going to be happening.
DR. MC DONALD: We can allocate some time to it and what advice we can on the legal ramifications.
MR. BLAIR: I thought there was a religious rule that we weren't supposed to meet in August. We never have. If we meet in August, then that changes the time frame and that's fine.
DR. MC DONALD: That probably means we should meet in New Mexico because it's cooler up there.
MR. BLAIR: New Mexico? Albuquerque, you're right. We could do that.
DR. ZUBELDIA: In New Mexico, it's over 110 degrees.
DR. MC DONALD: But it's dry.
DR. COHN: Well, it's about 5:25. Are there any other issues for today? I think we made some progress to start out all of this. We're going to be starting tomorrow at 9:00 am and we have a panel that has three people on it.
Is that right -- Sandy Fuller and George Arges and Bill Yasnoff will be here to comment and ask questions as he normally is, but he's actually not on the agenda. We will have discussions after that. Clem isn't going to be here, but Ted Shortliffe is.
Okay. Thank you, everyone.
Stan, thank you very much for sticking around and helping us clarify that last one.
(Meeting adjourned at 5:30 pm.)