[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