THIS TRANSCRIPT IS UNEDITED
National Committee on Vital and Health Statistics
Workgroup on National Health Information Infrastructure
January 7, 1999
Hubert H. Humphrey Building
200 Independence Avenue, SW
Room 405-A
Washington, DC
Proceedings By:
CASET Associates, Ltd.
10201 Lee Highway #160
Fairfax, Virginia 22030
(703) 352-0091
TABLE OF CONTENTS
P R O C E E D I N G S (10:07 a.m.)
DR. DETMER: Okay, we will start with introductions. Then, what I thought I would do is ask Mary Jo to summarize what we accomplished yesterday for Barbara Starfield, who is here today, and also ourselves.
Then we are going to have the Life of Riley. Dave is going to hold forth a bit, as you know, and then we will see where that sums up, and that will do it for today.
So, this is Don Detmer, chair of the national committee.
MS. GREENBERG: Marjorie Greenberg, executive secretary.
MS. ARAKI: This is Linda Araki. Hi, Richard.
DR. HARDING: Hi.
MS. ADLER: Jackie Adler, National Center for Health Statistics.
MR. RILEY: Dave Riley, representing Colonel Ray from DOD.
DR. STARFIELD: Barbara Starfield, member of the committee.
MS. HAYDOCK: Sandy Haydock from the Health Care Finance Administration.
DR. FRIEDMAN: Dan Friedman, member of the committee.
DR. DEERING: Mary Jo Deering, OPHS.
DR. HARDING: Richard Harding, member of the committee.
DR. DETMER: Great. Do you want to tell us what we did yesterday?
DR. DEERING: Okay. We began with the presentations of the three health records that had been outlined in the concept paper and then began to try to extrapolate from there what could be core elements for a matrix.
Let me back up and say that we had a brief presentation from the Office of the Assistant Secretary from Management and Budget.
They were unable to give us as much detail, or any detail, in fact, about the inventory that they have been preparing for HHS telehealth activities, but they did promise to have it ready for us in February and are very enthusiastic about working with us on that.
DR. DETMER: That is kind of a first, isn't it?
DR. DEERING: Yes.
DR. DETMER: That is good.
DR. DEERING: There is buy-in at the very highest levels to this effort, so I think that bodes very well for institutional continuity here.
In our discussions about the matrix, it quickly became clear that, on the one hand, there is an extraordinary amount of detail being done in the computer-based patient record already, that we would certainly not want to replicate.
On the other hand, it was not productive for us to try to proceed along the lines that we had originally mapped out.
At that point, Dave very helpfully spoke up about the work that DOD has already been doing in analyzing some of these issues related to the patient record, and even some that might have implications for the population record.
So, we are going to hear from him in a minute, to help us with our thinking there.
We did decide that we would focus more energy on looking at the work being done in other countries, specifically in the UK, Australia and Canada.
We decided that we would do this in a couple of ways. On one hand, we are going to have speakers present on the activities in those countries, and we are going to try to get Dr. Lloyd Reese(?) from Australia.
We are hoping that we can rope in someone from Canada. I had forgotten who it was who had contacts up in Canada who thought we could perhaps -- Marjorie, are you going to find someone --
DR. DETMER: We have got a name. Jennifer Zelmer.
DR. DEERING: Then I believe it was Steve from CDC who said he had read and reread and worked extensively with the UK document and that he would be prepared to perhaps summarize that for us at some point.
Then staff -- and I think it is Hedy and I specifically, and I don't remember if, Marjorie, you were called in on this, but we were to take a look at some of the outlines of these other countries' papers, in light of our own concept paper, and begin to see how they map, so to speak.
The goal would be possibly to write our own white paper, drawing heavily, as appropriate, on these other papers, plagiarism acknowledged, and looking toward maybe four or five recommendations for both the public and private sectors.
This white paper would also, though, draw not just on the experience of these other countries, but it would also incorporate what Don identifies as the drivers of health system change.
We are hoping to impose on him to give us a presentation as his valedictory, about what those driving influences might be.
MS. GREENBERG: It is on the agenda.
DR. DEERING: So, it would be the combination of other countries' experience plus our own American analysis of the drivers that would shape our white paper.
DR. DETMER: That is a great summary. Did all of that happen? I think it did, actually.
Do others of you want to weigh in? I think it was really an excellent summary.
MS. GREENBERG: It was.
DR. FRIEDMAN: Yes.
DR. DETMER: We are in sync. Richard, did that sound like what happened to you, too?
DR. HARDING: That is better than it sounded yesterday.
DR. DETMER: With that, why don't we turn the floor over to Dave, and you can lead us forward.
DR. HARDING: Dave, could you identify your position there with the colonel, and so forth?
MR. RILEY: Yes, I was going to give you some contextual information.
DR. HARDING: Great.
AGENDA ITEM: Presentation by David Riley.
MR. RILEY: My last assignment in the air force was to DOD health affairs, to the Assistant Secretary of Defense Health Affairs office.
I was brought to health affairs to be a chief architect for health care systems for the next generation of health care systems for DOD.
My background is, I am a primary care physician assistant, air force trained. I also have a systems background. My ability to speak tech and functional was very important to DOD, to have somebody in that position who could handle both the functional community and the technical community.
When I got there, I was charged with creating the strategic enterprise architecture for the next generation of systems.
I also wore the security certifying official's hat for all of our clinical systems that were being deployed. They all have to undergo C2 certification for DOD. So, I had quite a bit of visibility into all the security risks and problems that we had with our systems.
The third activity that I was over was, I had the title of chief of technology, discovery and insertion as well. So, I ran an advanced technology integration center for health affairs, with explicit charter of evaluating up and coming technologies and assessing their relevance to the architecture.
Then, if they were relevant or were becoming dominant market forces, how do I integrate those into our baseline architecture gracefully. That included planning from an acquisition point of view.
When I got there, we had 167 budgeted for systems for health care. Most all of them could not communicate with one another.
There was a lot of redundancy and overlap in the systems and many of them were obsolete and didn't fit with the current business practice.
My first task that I was asked by Dr. Martin, Ed Martin, who was the principal deputy assistant secretary of defense, and then the assistant secretary of defense for health affairs, was to create a common compelling vision for DOD health affairs.
That vision included three aspects to it. There was the business vision, where we did all of our business process re-engineering and understanding what it was that we were doing.
We were in the middle of a big transition from our traditional health care system to a managed care environment.
The second piece of that was what we called the functional vision or what more correctly should have been termed the IM piece of this, the information management piece. We separate IM from IT. From an acquisition point of view, that becomes important for a number of reasons for DOD.
Then the third piece was the technical vision, or the IT part of that.
So, we had, within about a nine to 12-month period, I had the task of developing a comprehensive vision, selling that to the three surgeons general -- air force, army, navy -- and all of the minions beneath that.
Then Dr. Martin empowered me that, if we didn't comply with that vision, he gave me the ability to take people's money.
By getting a hold of the purse strings, I could really become an enforcer. The other enforcement piece is that no system got deployed if it didn't meet security standards, and I held the keys to that as well.
Because the DOD health affairs budget comes down to a single person before it gets dispersed to the services, we had a choke point where we could actually control the flow of money.
So, that was the approach that we took there, and in just a moment I will run through the overall what we call health information infrastructure for DOD, and where that stands.
Then, I have some thoughts as to how we can transform some of that for this group, if you will like, so it will kind of jump start some of this, if it makes sense.
DR. DETMER: Yes.
MR. RILEY: I left DOD about 18 months ago and decided to get my hands dirty in implementation. So, I took a job with a little product company out in Reston, software development company, that was involved in internet and JAVA technologies.
The company is focused on -- I am not there any longer, but was focused on emerging technologies, basically, the strategic practical application of emerging technologies.
So, we used JAVA technology. Everything was object oriented. We were designing active, dynamic systems. That meant there were intelligent agents roaming the network, doing things.
What was more important was a product that we developed, a piece of security middleware that would allow you to use intelligent agents over your network, but do it in a way that didn't violate your security policies and allow people to just wreak havoc in your system.
So, I gained a lot of experience in direct management of software development process, understanding of market forces that drive the acceptance of software and the acceptance of technology, and so I got my hands wet there.
I was hired to create a health care division for that company. I came on at the beginning of July, hired my first employee in August, and we did $2.25 million worth of business in 10 months. So, we had some pretty good successes.
I left there at the end of October. Colonel Ray had been hounding me for about a year to come back and fix the messes that I got started when I was at DOD. He had asked me to come back as an independent consultant.
I left the company I was with in Reston at the end of October, and basically have my own little consulting firm right now.
I am on contract with Colonel Ray for a couple of things. One is to represent him at these meetings, these kinds of national meetings that he doesn't have the time for.
He is the program manager of a very large budget. So, it is just amazing how much all of his time is consumed.
I have two deliverables right now under the contract. The first that may be of interest to this group is what is called the health care interoperability paradigm.
We have a reference model that DOD developed on system interoperability. I have been tasked to specifically take that reference model and apply it to the health care domain, and plug in what is appropriate for health care pieces.
So, that deliverable will be delivered by May for that.
The second deliverable is, I have been tasked to lay out the data, integration and migration strategy for health affairs.
As I said earlier, we had 167 systems when I got there. We are now down to 52 clinical systems, and the target is to get down to four integrated clinical systems.
So, that means that we have huge masses of data that need to be integrated and resolution of the different data models, or what is called harmonization of the data models and coming up with a unified model. That is also due in May. So, there is a lot of work on the table for me to do right now.
DR. DETMER: It doesn't sound like the life of Riley to me.
MR. RILEY: No, it isn't.
DR. DETMER: A different Riley, obviously.
MR. RILEY: That is right; I wasn't born into that family for some reason. At any rate, just real briefly, a little bit of information about our health information infrastructure, as the term we use in DOD.
I would like to draw a quick diagram that shows where we felt like we fit in. If this large circle represents the NII, the National Information Infrastructure, the DII, which is the Defense Information Infrastructure, was a subset of that.
What was interesting is, we have a number of activities out here defining the health information infrastructure.
What was interesting to me is that, because we were part of DOD, we certainly were in this circle. We also were part of this other circle over here on the commercial sector.
I had to stay connected with what was going on outside DOD if we were going to have true interoperability.
The reason that was important, if we had stayed on our old health care model, we would have never had to really worry about interfacing with the private sector that much, only when we had to send somebody downtown when we didn't have those services.
Under the managed care model that we have implemented, each of our regions has about $1 billion or a $1.5 billion contract with a private provider for managed care services.
Now I have patients in the military systems who may or may not be seen in the direct care system. They may be downtown in the managed care system.
I have to have the ability to interchange information with those people, and do it more than just simply carrying a file over on tape or disk. I need to have a much higher level of interoperability.
I felt like, when I defined our HII for DOD, that we have acknowledged that, yes, I have people put over here in the operational side of DOD and there is a whole set of standards that I have to deal with there. I also have to be aware what is going on over in the commercial sector.
So, when I drew these circles, I drew them like this, where I had the NII big circle, the DII fully contained in that, and then a circle that was partly overlapping the DII and also in the NII for HII. That is kind of where we came from.
Now, how did we define it? The simple statement that we had here was that the health information infrastructure is a seamless web of communications, computers, software, data bases, applications, data and other capabilities, that meets the information processing and transport needs of the military health service systems, users in peace, crisis, conflict, humanitarian support and wartime roles.
So, we had an operational continuum that went from peacetime to full major conflict. We had to have systems that were developed in our peacetime environment that would be immediately transportable into our wartime environment.
If you have two different kinds of systems, then you have got the added expense and burden of training, both for peacetime and wartime. Here, you train one system and you are able to do it across your operational continuum.
This was a new concept for DOD health affairs, to do it that way. Traditionally, theater systems were developed separately from the peacetime systems, and they were carted off to war.
That data may or may not have been captured and, where it was captured, it never got back into the peacetime system. So, there was not any real communication there.
Now, when we defined our business vision, we came up with what we call the C9 definition of this health information infrastructure.
The C9 definition was the HII is the convergence of computers, communications and content to create collaborative communities to convey care, C9.
DR. DETMER: That is good.
MR. RILEY: There are several characteristics of it. It is convergent, meaning that you have convergence going on in each of these three areas here, in content, computers and communications.
It is simultaneous. In order for this thing to really come to fruition, the convergence that is going on here has to reach a certain critical mass. There has to be simultaneity across this.
It has to achieve ubiquity. We have to put it everywhere in order for it to become the driving force for us.
It is emergent, there are collaborative communities that emerge out of this environment. The two broad categories of communities are the provider communities, and this is where you have the opportunity to do your continuing medical education and you do your telemedicine-type consultations, where one physician is consulting another about a particular patient.
You also have your consumer or patient communities, which may involve them accessing medical information to help better their ability to take care of themselves.
It may be putting all the breast cancer patients together on line, to be able to have a support group where they can ask questions of one another, or maybe have a moderator from time to time, who is a medical person, who is able to support that.
What we saw was a very dynamic environment with a lot of activity going on in terms of the potential for thinking of it more as an ecosystem, as I said yesterday. We talked about that a little bit.
Basically, the reason why I came up with the C9 definition is because this diagram is a simplification of this one.
DR. DETMER: What are all the Cs, first?
MR. RILEY: It is convergence of computers. You have got to have the convergence, that is one of the Cs.
The convergence of computers, communications and content to create collaborative communities that convey care.
The reason I shot for nine is because the medical aircraft in DOD that are dedicated just for health transport is actually the C99. It is the McDonnell Douglas C99.
So, there is a connection in what we are doing. A lot of people got the connection in DOD. They said, oh, that is cool. So, that gives you some background on that.
So, we have these three areas, communications, computers and content. I was tasked to basically monitor a lot of activities in those areas, to find out what the standards were, what was emerging, what was dying, what seemed to be the direction.
I basically was given a crystal ball and said, look in this and tell us what we need to do next. Should we buy this or should we not.
In order to do that, I developed several models. I will come back to this in a moment, to talk about these services.
I had to come up with a way to think about architecture. Historically, architecture has been a word that has been used a lot by a lot of different people with a lot of different meanings.
We went back to the IEEE standard 610.12 definition, which basically says that architecture is the structure of components, their relationships and the principles and guidelines governing their design and evolution over time.
From that, we decided to create an architectural framework which would allow us to evaluate architectures. This is the era of architectures.
Right now, in the software industry, you have two major competing architectures -- well, three now.
You have the Microsoft architecture, which is based on a proprietary standard that Microsoft is bullying the market with.
The second standard is the CORBA Consortium which is distributing computing. Then the newest thing on the block, which has taken everything by storm, is JAVA, the JAVA technology.
What is interesting is, we are seeing the convergence. JAVA is kind of consuming the DECOM and the CORBA models as well. I think it will be a force that will absolutely have to be contended with.
The important thing was that we had to think, as we looked at all these systems -- I had 167 systems to look at -- how could I evaluate them and make recommendations to the decision makers as to whether this system needed to be terminated or not, whether it was worth the money to make this system talk to that system. We didn't have any real way to think about that.
We had to come up with two things. One was our architectural scalability reference model, which is what we are looking at here.
The second thing was our levels of information system interoperability reference model. Using these two tools, it gave us the framework that we needed to be able to think about interoperability.
It gave us a context within which we could create measurable outcomes, if you will, so that under IT MRA, which requires us to be able to do these things -- the Klinger Cohen Act -- we would have accountability from the government's point of view.
The architecture of scalability reference model basically has seven levels in it. It goes from the most granular level, which is the actual creation of objects in the system, and the definition of those objects.
In the particular language like JAVA or C++, there are what we call idiomatic patterns here. Each one of these levels have architectural patterns associated with it, which either increase efficiency or decrease efficiency for that particular level.
The next level up is what we call the microarchitectural level. This is components. You may have heard a lot of buzz in the industry about component-based software, JAVA beans, that sort of thing.
The next level above that is what we call the macroarchitectural level for software, and this is where software frameworks come in. Enterprise beans is an example in the JAVA world.
These are things that are hands-on programmers writing codes kind of thing.
At the fourth level, we get to the application architecture level. It is at this level that you would have to deal with performance and functionality.
Decisions that you made down here may affect it, but it is at this level that these become really the dominant forces.
I have listed a set of forces over here on the side, forces meaning, we have to resolve these one way or another. They actually become dominant at a particular level, and I will point them out as we go along here.
It is at the application level that performance and functionality become dominant concerns, that you have to be able to design your application to perform for the end user and you have got to deliver functionality, and this is where you do it.
You do it by combinations of these things. You may pick a set of frameworks -- JAVA beans of Active X, Direct X, whatever -- and within that, these are all very well documented at this level. Again, there are several pattern books that document that.
The next level up is the system architecture level. This is where you are aggregating sets of applications to put together to deliver a system.
It is at this level that the two dominant forces that you are dealing with are the management of change and the management of complexity.
At the next level above that is the enterprise level. This is the level that I was working at in DOD. So, when I talk about health information infrastructure, the reason why I say I am working at this level is because at this level I still have the ability to direct and control.
I can cut out budgets; I can deny somebody from being able to do something; I can give them direction; I can grant a waiver on a particular policy that we have set or what have you.
It is at this level that we set things like policies regarding standards that the organization is going to use. We create a common operating environment. We create application profiles that, if you are going to work in this environment, you have to do these things.
In DOD we have the common operating environment. We have an integration and run time specification that, if you were going to run in our system, you had to be able to meet those requirements to be able to do it.
These things were not arcane or unique to DOD. We spent a lot of time looking at what the industry was doing.
So, we had a joint technical architecture at this level that specified the whole set of standards that you could use. We had a way of looking at up and coming standards and insert those into it.
The highest level is the global architecture level, and this is where you have got multiple enterprises that have got to come together and work together to get anything done.
Really, if I were to place this committee, this is where you sit, at this level here. When you look at the global level, the model that I use to talk about the global level for health care, is this model here.
So, as a government committee, you fit into here in this ecosystem. You have the ability to look down over all the rest of these levels.
You may or may not do anything directive here. What you are primarily focused on here is the passing of laws that prevent extreme things from happening.
You cannot be as directive as at this level here, where I can mandate a particular thing. You may try, but it may not go over very well. That is kind of the level you are working at.
Really, you are working at this level in terms of alliances and collaborations and joint venture kinds of activities, where you are not able to coerce, but you are leading by example, those kinds of things.
It is at this level that the dominant forces are in the management of technology transfer and the IT resources. These kind of both go at this level here, but they have a different meaning at those two levels.
By doing this, we were able to create seven levels of abstraction, if you will, to be able to kind of cull out these levels.
If I was talking to a system developer, who was working on the system architecture, I knew that he was primarily concerned with change management and the management of complexity.
So, when we were planning that system architecture, we made sure that these guys down at this level, at the application architecture level, didn't do anything that was going to compromise our ability to manage change and complexity.
At the enterprise level, when I was looking at these guys below me, I would have to be concerned with the management of IT resources.
One of the things that is going on at this level is now I am having to deal with change across multiple systems.
A good example was, because a lot of the programs were not coordinated, we might have five different systems that were being implemented at a hospital one month after the other, and that is very disruptive to the business process within a hospital.
So, we had to be able to coordinate those things and conserve resources. When I got there, it was not unusual for a system to come in and put a complete new backbone into a facility.
I went into facilities that had six backbones in them. We had one system go out and put in a 24-strand fiber backbone, which was enough to carry all the traffic for everything in the facility, but they didn't want anybody else to run it.
So, we had to resolve those issues. We had to come up with and decide on a common infrastructure for the facilities. So, we had to deal with all those issues.
In order to do that, we had to come up with a way to think about it. So, this was our way of thinking about it.
This is what we call the architecture scalability reference model. When I deal with people in DOD, I immediately place them at one level or another on this chart.
I know immediately what their main concern should be. At the applications level, it is these two, at the system architecture level it is these two, at the enterprise level it is these two, or at the global level. Most of the time I am not dealing at this level in DOD. It is level 6 and below.
Then there are sets of concerns down here at this level. When I am talking to a group like this, I don't usually bring that out, because it is technical detail that you are not really probably interested in.
That brings us to the interoperability reference model, which I will just touch on quickly.
There are five levels in that. I didn't get them all written up here. Basically, what they are is level zero is isolated, which means they are not connected at all and they are not able to transfer files between each other at all.
Level one is connected. That may mean you just are able to do things like Telnet, FTP, E mail, text chatter, IRC. You have an electronic connection, but you have completely separate data and completely separate applications.
At level two, this is what we call the distributed level. You have minimal common functions. You still, for the most part, have separate data and applications.
It is at level two that the world wide web fits in. That is the ability to do http, the use of the NITF, national imagery file formats, those kinds of things.
At level three, we call this the domain level. It is at this level that we have shared data. We have now begun to resolve some of the data base issues, but for the most part, we still have separate applications.
If you are going to do something to that data, you are going to have to switch applications in order to do that. You don't have the full integration that you want.
Level four is what we call the enterprise level. It is at this level that you have interactive manipulation, shared data and applications.
It is at level four that we envision what we call an information space and a collaborative work space.
Rather than you having to know the location of data, you basically just sign on the system. Because of the security mechanisms in it, they are able to deal with what you can get access to.
It is location independent; it is location transparent, and you have all the collaboration tools that you need to be able to create a shared understanding of what your problem is and how to get that problem solved.
So, the concept of an information space becomes very important to this, in terms of having subspaces within that, and I will talk to you in a second about how we applied that to the patient record thing.
DR. DETMER: What is one again?
MR. RILEY: One is what we call connected. It is simple connection. You have an electronic connection. So, you can do things like out Telnet, FTP, E mail, and IRC text chat.
Now, this slide would probably be of interest. It is busy, but it shows the five levels of the interoperability model, and the major documentation that is associated with that.
We have what is called the DII master plan. I think, of all the documents that are on here that would be of interest to this group, this would be the one.
We have an equivalent document that we are working on called the HII master plan. We decided that it wasn't worth the effort to continue a separate effort from this, so we rolled that activity into the DII master plan, as an appendix to it.
This really is the DOD's information infrastructure master plan. It lays out the goals; it lays out recommendations. It is this kind of format.
You may not call it a master plan. You may call it the NHII strategic plan or something like that. But it is that plan that I think would be of interest to this particular group.
I am trying to track down the most recent version of it. I should have that by the next meeting. Then I can summarize and show how I think that it fits.
DR. DETMER: Great.
MR. RILEY: The other documents on here, as I said, at the enterprise level you are going to mandate things like a common operating environment; you are going to mandate things like a technical architecture where you have got a set of standards that you say, if you buy or build systems, they will be compliant with http, they will use XML, or whatever it is that you happen to be able to focus on.
So, in this document we have the DII master plan. This is the specification for what that common operating environment is. There are seven levels is that, in terms of the integration and run time spec.
Its focus is on de-conflicting the run time environment, so that when you install software, it works, and you don't have to worry about it stomping on some other program.
The joint technical architecture is, again, basically the standards profile. It says, you will use this format when you are talking about images, you will use this for transport, this kind of application.
For instance, we mandated the use of HL7 and the use of HDTP and those kinds of things.
The other one over here is the one we call SHADE, which is our shared data environment. This is our initiative for creating common data repositories, common information repositories, within DOD.
So, there are three types. There is universal data, which is things like states, abbreviations, that kind of thing, common to a lot of applications.
Then there is what is called shared data, which is usually within a domain you are sharing data across multiple applications or multiple systems. Then there is unique data as well, and we try to minimize that as much as possible.
If it is unique to a particular system, we still try to mandate formats so that it would be self describing. So, the use of XML is very important. The ability to have self describing data objects means that you can discover in the run time environment what it is, what their semantics are, and how to use that data. Those are new concepts for DOD.
This kind of relates the major documents to the interoperability model.
DR. DEERING: Can I ask again, what was the JTA?
MR. RILEY: That is the joint technical architecture. We use the architecture word a lot, unfortunately.
We had what was called the TAFIM, which basically was a compendium of every known standard to man. So, originally we directed system developers, you have to be TAFIM compliant.
They would go and say, this is like a menu, this is great. I don't care whether it talks to this other system or not. They are using that system; I am going to use this one. Vendor lock in.
So, we figured that out after I don't know how many years, and decided that that wasn't working. So, we knew we had to narrow down from the universe of all these standards to something that was more workable in our environment. That is why the JTA was formed.
So, there is an intermediate level of document. There is TAFIM. Then below that is what we call the architectural framework for C4I. That is our systems -- command, control, computers, communications, intelligence, for surveillance and reconnaissance.
So, they have an architectural framework. Within that they have a set of meta data elements about architecture. So, that really provides the framework for evaluating architectures.
DR. DETMER: What is the level of meta architectures in this?
MR. RILEY: Okay, that is a good question. It is right here. This level, the way to handle this level is what we call vertical interfaces, horizontal interfaces and meta data. Those are the three major patterns that you are going to enforce here at this level.
This is where meta data becomes very important, because that allows systems to discover about other systems the information that they need, in order to be able to interoperate in the run time environment.
So, for example, if we were doing object oriented development, then you would say that all your interfaces at this level have to be in IDL interface definition language.
For meta data, we would use a meta data standard like CDF or one of the ones that is popular on the internet right now, using XML. That is the way we are going to do it. We have already started doing that inside Health Affairs.
It is at that level where you are going to apply those patterns. Horizontal interfaces means things that are common across systems, and that is what brings us back to this level.
The horizontal interfaces are these back plane services. The ones that we have identified in DOD historically have been distributed computing, systems management, security services, and internationalization services.
The two that I have added for health affairs, if you go to a completely paperless, filmless environment, you have to meet the requirements of evidentiality.
Evidentiality is the things that you provide for legal evidence of what you are doing in your business, and it is not just health business. Any business that wants to go completely paperless has to satisfy evidentiality.
The discipline that this comes out of is archives and records management.
That also addresses the question of what is the purpose of a record. Most people give me all these usages for a record, but the basic purpose of the record is to preserve the content and context that is committed to it, and to be able to allow that to be retrieved.
If we go back to our C9 definition, one of the things that I talked about was collaborative communities to convey care.
Collaboration is the development of shared understanding. It is not just simply communication; it is not solely new data.
We are overwhelmed with data. We have to have tools that allow us to be able to develop a shared understanding of the problems we are dealing with and come up with a solution set. So, we need collaboration spaces, if you will, that allow us to deal with that. In medicine, one of our greatest collaboration spaces right now is the record. It is where the provider and the patient sit down together and come to a shared understanding of what is going on.
If you look at it as a collaboration tool, then you begin to see the record as more than just simply a data base. It is a very active information environment.
DR. DETMER: This is where we start hitting the behavior wall in these systems.
MR. RILEY: Yes. The three years that I spent at Health Care, one of the projects that was one of my pet projects, my favorite pet project, was what we call the collaborative health care environment.
I was specifically interested in the integration of voice, video and data at the desk top, and figuring out a way that would allow telemedicine to be integrated as a natural part of my work flow as a provider.
When I am sitting in a clinic seeing 40 patients a day, between 7:00 o'clock and 4:00 in the afternoon, you didn't have time to get up and go down the hallway to the telemedicine suite, to interrupt your flow to do a consultation.
Right now, for the most part, telemedicine is that. You have to schedule this equipment, the person to run the equipment. The patient has to be there, you have to be there, and then somebody has to be on the other end.
So, it makes for a major disruption in the way I do business. Now, I can plan that. I had minor surgery days and PAP smear days and things like that, where I had a special day set up where I might only see 12 patients for the day or whatever. It certainly was disruptive, the way we were doing telemedicine.
I wanted to explore, how can we support in the system the three types of collaboration -- formal, ad hoc, and informal collaboration.
I was primarily focusing on informal collaboration. Formal is well defined in terms of work group tools. You can buy Ventata, Work Group for Windows, and you can run a structured meeting, where you have an appointed agenda and time and place and people, and everybody comes in and you do all the things you are supposed to do.
Ad hoc is basically a situation arises and you assemble the crisis team to manage it, but it still has quite a bit of structure to it.
It is the informal collaboration that occurs when I go to the water cooler and come back and I stop at your cubicle and you are working on a problem, and you say, have you dealt with this before, and before you know it, real work is being done.
So, what we developed was a spatial concept that allowed us to create this work space, what we call the collaborative virtual work space.
We used a spatial metaphor because people were comfortable with the idea of offices in buildings. So, in this virtual space, we actually created a building that had floors, and offices on each floor, and you could navigate through that space.
As you navigated from one place to the next, your voice, your video and your data were connected under multiple task ID groups, the underlying technology. I don't want to get too deep into it.
Basically, everybody who was in that room, you would see their video, you would hear their audio if they wanted to talk to you, and you could do textual chatter. You could drop files into that room, give them to another person, take files from them, and you could interact with them.
The idea was that in this environment, if you created it, you could incorporate this in your desk top environment.
Let's say this is our building and we have got a hallway here, and there is an entrance and there are several offices here.
Let's say we have got an office for all the cardiologists who are going to be on call to take telemedicine consultations.
If I am seeing a patient and I have got something going on and I want to talk to the cardiologist, what I would do is cruise over to this room.
They could leave an icon of basically their picture, and you could actually click on it and get their credentials below. It would tell you who they were and where they were located if you were interested.
The idea is that you could double click on this, and if that person were at their work station, it would beep them.
If they were not, it would beep their physical pager out in the system, and let them know that they had somebody needing to consult with them.
They could come back. You could instigate a textual chatter. So, you have a dialogue box.
If you wanted to share an EKG over them, you could do that over a white board, or you could share that directly.
We didn't have all of that implemented in terms of doing it outside of a white board, but basically we could capture it as an image and put it on a white board and you could do mark up on that.
We also looked at the integration of things like the electronic stethoscopes if you wanted to listen to heart sounds.
If you wanted to go full screen, high resolution images, you could do that. Of course, it took a lot more band width.
The idea here was just to look at what is the work flow and how can we incorporate this in the work flow.
Now, rather than having to get to a scheduled specialty, if I had a new business process here to support this, I could be seeing patients, and I have my charting application up and all, and hey, I need to talk to somebody about this.
So, I just pop into this room here and I see who is on call, and I double click on them, and in a few minutes, while I am talking with the patient, they are going to come back up and we can begin the dialogue at that point.
Now, how do you document all of that? That is a whole other issue in terms of capturing the context, and we have been doing a lot of work on that as well.
There were work flow tools that would allow you to flow. If you wanted to do consult tracking, you just wanted to initiate the consult and, over time, it needed to go to somebody to approve it if it is at the HMO level, and then it went over to the specialist and then it was scheduled or what have you. These are all things that we are looking at in this particular environment.
As I said, this was my pet project, so we don't want to get on that. I could spend days talking about it.
Where that is now, the DOD is ready to begin. They have a beta test group up and running with this now, over at Health Affairs.
So, we are just beginning to use it in the office environment, and then they are going to extend it out to the broader health care environment.
We are going to capture all of this and then we can dialogue with that patient at all times.
DR. DETMER: They could make rounds.
MR. RILEY: They would make rounds. They would check the pulse oximetry. They would look at the child's breathing, because they could see him over the video connection, and they would make adjustments as necessary to their treatment.
The goal was to obviously make their lives more livable so they weren't having to spend it all in the ER, and defray costs, if you will, by not having these kids in the emergency room.
In six months, they saved $500,000, and that is documented.
DR. DETMER: Does that include the start-up costs or just the operations costs?
MR. RILEY: I have not seen the final report, but they have told me that it includes all the start-up costs.
So, there was a significant savings. So, what this allows us to do, if we take this metaphor -- now, they weren't using this particular software to do that; there was some other software that they were using.
If we take this piece of software, basically, what we can do is create, in this context, integrated with the web TV front end, we can create a room that the parents know that this is where their nurse manager is going to be, or their physician or whoever, that they need to talk to.
DR. DETMER: On the flip side, the nurse knows what rooms to go to, to get the patients.
MR. RILEY: Exactly. So, we have a way to be able to provide a meaningful, collaborative work space within which people can navigate.
What we found is that the more realistic we made this graphic here, the easier it was for people to immediately get into it and start getting comfortable with it, and be able to navigate it and work in it.
For example, if you went into the records room, there was a copier object there. It was an image of a photocopier.
We didn't have to tell people that if you drag, click and drop the record on there, it is going to make a copy. They just intuitively knew that.
DR. DETMER: A guy at UVA has laid out one of these, actually the physical lay out of our emergency room, with all the rooms, all that, like the old grease board. It worked phenomenally well, because everybody kind of knew the physical structure. It is very convenient.
MR. RILEY: There are all kinds of things we can do with this concept of the virtual space. Once you get people in it and get them comfortable with it, then you can create more complex structures that are more meaningful in terms of being able to get large amounts of data and process it quickly.
DR. DEERING: I don't know -- this is still a clinical model; is that what you are getting at?
DR. STARFIELD: So far it is, I think, a clinical model, and I guess I am sort of interested in your distinction between surveillance and reconnaissance. It is kind of neat.
Surveillance is you know what you are looking for and reconnaissance is you don't know what you are looking for. This is relevant to that. You can get the oximeter, but it doesn't give you the GI symptoms for medication and that kind of thing.
MR. RILEY: Actually, we are hoping to be able to plug in those pieces as they are developed, or some of them are already developed, and we want to plug those in as the next step.
This program now is really pretty stable. We just want to get more users in the run time environment using it, in terms of looking at latency and performance issues.
We used the multimedia backbone or what they call the MCAS backbone of the network for moving video over, with basically anything from a dial up to 56kb line or T1 line, you can get relatively good video.
If you go to full screen, then obviously you slow down quite a bit. Our idea there was to be able to use the H.324 standard, which would allow us to create different levels.
DR. DETMER: Is there any description of this at all on a web site, or not?
MR. RILEY: I don't believe there is anything on the web site, but what I can do is, I can get you a description of it. I can probably bring that at the next one, including screen shots of the current version they are doing.
I had a lot of difficulty getting people to separate the user interface from the underlying functionality, conceptually.
I went through three contractors before I got one who could build what I wanted. So, it took a while. We are struggling with that.
Any other questions along those lines?
I wanted to kind of walk you through real quickly -- I made some statements about this yesterday, in terms of doing an analysis of the computer based patient record.
I did a phenomenological analysis and I wanted to show how all of those things that I enumerated as areas that I was monitoring yesterday came about.
Initially, what I did is I envisioned a patient who detects or is concerned about their health care status. Maybe they are interacting with some kind of a disease entity or something in the environment or something internal, or what have you.
There is some kind of interaction goes on here, a perception takes place and they want to know their health status, or they are ill and they want to go in and be seen.
So, they go in and they have this encounter, which I view as the central transaction of health care right now, is the encounter between the provider and the patient.
There are a number of things that take place here. What falls out of that is content, in the form of documentation. There is also context here that needs to be preserved.
When I began to analyze this, I began to analyze, what are the underlying things that I need to be concerned with here, if I am going to build robust systems that are going to be able to support this process.
One of the areas that I first set on was knowledge representation and reasoning. That may not be the correct term. It may be Jeff's term yesterday. I think he talked about data representation.
The most important concept that I hit on here was that we had to have the ability to represent this information and to reason about it.
The thing that I found was that there are three levels at which we do that. There is a terminology model, so this is where we identify and represent medical concepts -- for example, lung, mass, chest X-ray. We have a basic representation for those things.
There is an information model, which basically is rules or templates on how to combine the medical concepts in order to produce meaningful medical descriptions.
So, you go from just terms like lung, mass and chest X-ray to the level of where you can now talk about a chest X-ray talks about lung mass. So, you get data structure and grammar involved here.
The third level is what we call the knowledge model, and that is your knowledge base. This is where your known abstractions and relationships among medical concepts are enunciated.
So, now you go from chest X-ray shows lung mass to go to be able to reason and say, a lung mass may be caused by lung cancer.
Now, what is interesting about breaking this out this way is that we can take some of the activities that we talked about yesterday -- for example, the Galen project; where does that fit into this.
They are basically operating primarily at this level, there is some at this level, but there is very little that I am aware of at this level, at this point in time concept that I hit on here was that we had to have the ability to represent this information and to reason about it.
The thing that I found was that there are three levels at which we do that. There is a terminology model, so this is where we identify and represent medical concepts -- for example, lung, mass, chest X-ray. We have a basic representation for those things.
There is an information model, which basically is rules or templates on how to combine the medical concepts in order to produce meaningful medical descriptions.
So, you go from just terms like lung, mass and chest X-ray to the level of where you can now talk about a chest X-ray talks about lung mass. So, you get data structure and grammar involved here.
The third level is what we call the knowledge model, and that is your knowledge base. This is where your known abstractions and relationships among medical concepts are enunciated.
So, now you go from chest X-ray shows lung mass to go to be able to reason and say, a lung mass may be caused by lung cancer.
Now, what is interesting about breaking this out this way is that we can take some of the activities that we talked about yesterday -- for example, the Galen project; where does that fit into this.
They are basically operating primarily at this level, there is some at this level, but there is very little that I am aware of at this level, at this point in time.
When I was at DOD, this became a hot issue with us when we were beginning to integrate these disparate data models, because they had semantic inconsistencies across them, and I had to figure out a way to resolve those.
So, what I did is, I spent a lot of money. I basically went out to industry and found what I could identify at the time as the significant lexicon of activities in the commercial sector.
I brought in people like IBM and 3M and Micromedics and PKC and a little company called Serius, which all had large installed lexicons of clinical data, or clinical information that were running in run-time systems out there.
I coupled them with, I had five commercial vendors and seven government contractors all working together on this project.
Our idea was to figure out the best approach to this clinical lexicon issue.
DR. DEERING: Was this strictly at the VA? I was RAV involved in this?
MR. RILEY: RAV wasn't involved in this initially. I had some real operational deadlines that I had to meet. I went over eventually and briefed RAV about what was going and we were working to try to get a collaboration going. They are involved in that now.
MS. GREENBERG: I know they had a meeting maybe six months or so ago.
MR. RILEY: It has been an interesting experience. What I found was, we brought in people like Stanhoff(?) and all those people who wrote papers, and we talked about an optimal design for a lexicon and what does it mean in terms of terminology and knowledge models and information models and all that kind of stuff.
What I really wanted to be able to do was to take the content that 3M had, which they have a huge amount of content; we are talking about 27 years worth of work.
Really, the tools they were using were not the best for my environment.
DR. DETMER: The HELP?
MR. RILEY: Yes, they had transferred it, the technology, and that is where a lot of it came from. Like, IBM, it turns out they have no content, but they have a knowledge representation tool.
So, all their knowledge is owned by others. They don't own that content. They own the development it, the technology, and that is where a lot of it came from. Like, IBM, it turns out they have no content, but they have a knowledge representation tool.
So, all their knowledge is owned by others. They don't own that content. They own the development.
So, IBM's solution was to come to me and say, well, let us develop all the content for you. It took them 27 years to get to half a million concepts and four million synonyms. What makes you think I am going to pay you to do that.
So, what I finally got them to agree to, companies like Micromedics and PCK, PCK has a lot of terms and concepts related to actual delivery of care at the patient level. They have done a lot of contribution to Snomed's vocabulary as well.
What I convinced them to do was merge all of the content under a single information model. What was born out of that was what was called the Clinical Lexicon Consortium that four companies formed to be able to support the government on this.
MS. GREENBERG: What is the relationship to Snomed?
MR. RILEY: Snomed, basically, we incorporated that. We were trying to incorporate as many vocabularies as possible under a common set.
DR. DETMER: What percent of the total lexicon is Snomed?
MR. RILEY: I don't know the percentage off the top of my head.
DR. DETMER: Just a rough estimate; 60?
MR. RILEY: I don't know that it is 60. We had a lot of additional.
DR. DETMER: Probably 40?
MR. RILEY: Probably 40 or less.
DR. DETMER: About how much of the others are kind of defined and how much is still literally R&D?
MR. RILEY: There is still a lot of R&D left. Twenty to 30 percent is probably still under R&D. You know, we had LOINC and we had all these different vocabularies that we were basically rolling into this lexicon.
DR. DETMER: So, the total UMLS would be 70 percent maybe?
MR. RILEY: That is our foundation that we started to work with. So, UMLS was a foundation for a lot of this.
Now, what was interesting is 3M had modeled everything in an ASM1 syntax, which is a good way to do that.
I think we finally convinced them recently, the Clinical Lexicon Consortium, to move to XML technology, which gives us a lot more flexibility by creating self-describing data objects, but that remains to be seen, where that is headed, actually. They are still in negotiations on that.
The meeting that you were referring to earlier, Marjorie, this past summer was probably in the context of the government's CPR initiative.
MS. GREENBERG: Right.
MR. RILEY: There was a lot of concern suddenly raised -- I don't know who raised it -- as to whether this was the right information model to move forward with.
There is no right information model; it is constantly evolving. DOD has operational demands. That means that they have to get something out there, you have to make a decision and move forward. It is not something that you can spend years and years studying before you deploy anything.
I was called back to provide a lot of the context, since I was the one who started this project, to be able to answer questions in relationship to that.
I probably wasn't in that particular meeting, but I was in a follow-up meeting.
DR. DETMER: This piece of this has a lot of relevance, as you know, to the standards piece that is part of our main description.
MR. RILEY: Exactly. As a matter of fact, as I finish this, this was one area alone where, as you can see, there are a lot of standards activities going on here.
There are a number of models that we can talk about and I can list them if you want, in terms of the REM, the reference model from HL7, the clinical process model from COSMOS, the TOVE technologies from the Toronto Virtual Enterprise. There are a whole bunch of these that actually, at first glance, they look like they are at cross odds, but they are at different levels of abstraction.
Once you realize that, from an architectural point of view, then you can figure out how they can be harmonized. That is primarily what I am working on now, in terms of the data harmonization tasks that I have.
So, for example, the HL7 reference model, the message development framework is a subset of the architectural framework that I talked about earlier, and defines a process by which you define your models. So, it is a meta process, if you will.
That is very useful in terms of the modeling efforts in DOD. Historically, we have used IDEF modeling and ended up with activity models and data models, activity models which are supposed to be your business, but every time I have shown them to our business leaders in DOD, they look at this complex thing on the wall and are like, I don't see my business in that.
So, we have to have better ways of representing this. So, now we are using UKASE models and things like that, that allow them to look at that and say, yes, definitely, I see that; I understand that.
We have kind of had to hide the modeling gurus behind the scenes in terms of the IDEF stuff, in order to get the business people to buy into it.
DR. STARFIELD: Are you talking about vendor data capture?
MR. RILEY: Yes. Part of that whole thing on the IDEF modeling is that we are beholden to one particular contractor on that, and I have been trying to break their death grip on us for a long time. I think I am about to succeed.
DR. DETMER: I would like to see, if you could, in about 15 minutes, try to move so that we are finished, trying to also fit, if you can, this piece to where we are. Is that fair?
MR. RILEY: Yes, I think so. The other areas that I mentioned were temporal representation reasoning. This is where you have to deal with the concepts of time.
There are multiple types of time that we deal with in systems. There is the system time. If you are talking about data base, there is the time that the fact was committed to the data base.
There is also a decision time that needs to be captured in the record. We need to be able to acknowledge these, recognize them, and represent reason about those. That becomes particularly important when you start to do population stuff.
Spatial representation and reasoning, again, there are research activities going on in all of these areas.
On time, John Allen, his 1983 paper, looks at temporal calculus. Every researcher that I have ever checked on that has anything to do with the representation or reasoning of time refers back to that paper. So, that is a seminal paper. Mark Musson(?) and Nuval Shahar(?) at Stanford have done a lot of work in this area as well.
Spatial representation and reasoning, I haven't seen a lot on this yet. Nuval Shahar took their model on temporal representation and reasoning, and suggested that this problem is the same class problem as this, and it would be interesting to take these tools and see if they would work on this kind of a problem.
He has applied that and the hypothesis tests out to be at least so far true, that that is the case.
So, there is research going on now in the medical context related to this particular problem. This is important to us, as I said, if you bomb a chemical munitions dump and generated a toxic plume. Who was where and when, so you know what their exposure was, that type of thing.
Then you have to be able to represent and reason about personal identity or persons. In this case, you are reasoning about patient identity and you are also reasoning about provider identity.
DR. STARFIELD: And the context?
MR. RILEY: Yes, I get to that. When you talk about security, there are several things that you have to be able to reason about in terms of this model here. One is the sensitivity level of the data, which has to do with the content here. The context that you reason about under security is the relationships.
For example, you are my primary care provider and I am going to give you access to my information. In a world where the patient has complete say over who sees their information, we may not get there, but it looks like we may head that direction.
Then this becomes very important. The other thing here is tasks. Within the context of this task and this relationship, do I need this piece of information to be able to get my job done.
What we end up with is role based access control, task based access control, sensitivity based access control and activity based access control models. So, the security piece to make this really work is not simple.
We are beginning to really get our arms around it. Like I said, I was the security certifying official for DOD, and I have had a lot of time to think about these problems.
I can tell you that the United Kingdom is ahead of us in a lot of these areas in terms of sensitivity and confidentiality, and they are doing some pretty neat work over there.
We spent a lot of time looking at it in the context of dynamic information systems, how do you implement this so that you can get this in the right type environment.
We have had a great deal of success with role based access control. We have completely implemented the role based access control model.
We understand the -- the other work here for relationships, and the British model is accountability. Accountability exists between a provider and a patient, or a provider and an institution, an institution and a patient, an institution and a specialist.
We see this also in the Australian model as well. I don't remember the exact terminology.
Basically, the other thing that we have to be able to do is connect person with content. So, this is where your indexing directory type stuff comes in, that allows you to connect the unique person identified with the work related information.
You have to be able to disconnect those two if you want to aggregate and anonymize data.
That plays into your security model, because if you can identify the subset of data -- this is the way I have approached this particular problem.
If you -- the universe of all the data that would be in the health care record, the person data is a small and potentially well-defined set of data in relationship to this big mass here.
If you can identify this, then U-T becomes health data. When you combine health data plus personal data, you get a personal health fact, and this has a sensitivity level associated with it.
If you have just simply health data, it is basically non-sensitive, if it is completely anonymized.
There are some exceptions to that. If you have someone with a very rare disease, you can probably figure that out.
Basically, this would be non-sensitive. This would be the first level at which you would have sensitive data.
Then what you would do, you would have a flag here that allows you to mark it as highly sensitive. So, if this is checked, then when you combine these two together, then it becomes highly sensitive, then within the context of your relationships and the task, to determine whether you have access to that or not.
Then there is actually a set theoretic model that we developed for this.
Let's see if I can pull it all back together.
DR. DETMER: This fits, obviously, also into our security piece.
MR. RILEY: Right. Basically, what I have done over the past three years is, we took these models that we had in the DOD side that were being ongoing and I tried to tailor them for health.
I began to ask about content, for example. This is all basically at the content level on this model here.
So, I would say, on content, what do I need to be monitoring in terms of standards and activities that are going on.
So, I have got knowledge representation, temporal, spatial, and security, person, indexing, content and context in terms of evidentiality, and paperless and filmless environment.
I actually have contractors monitoring activities in this area, pulling research and stuff like that, not having to do all that myself. At least I have a way to think about that.
Within this, I look at and I use what we call the PAID paradigm out of our interoperability environment. Basically, PAID stands for procedures, applications, infrastructure and data.
So, I monitor each of these activities, from procedures meaning doctor and meaning policies and those kinds of things, architectural things, technical things.
Then, in the applications area you have a set of activities that you monitor for. Infrastructure, you are looking at hardware, communications services and security, data, and the kinds of things we have listed up here.
So, we have a way to think about these problems and track them. So, the question is, can I come up with a useful matrix for this group based on that, or are you interested in that kind of a matrix. I don't know.
I can associate with most of these things the research activities and the product activities that I know of out there in the marketplace. I don't know whether that is going to be useful to us at the end, when we are all finished with it.
DR. DETMER: I guess, just to give my own reaction to this, the point that you mention, that DOD both has had prior to this effort, which is a huge effort in interoperability, both on the content as well as the technology -- the hardware as well as the software side -- it seems to me that if we are talking about a more cross functional national health information infrastructure, assuming that you can build a securities software, it is clearly a more sensible way to go globally, as far as that goes.
So, from my perspective, to have us be able to get something from you that kind of sketches out that sort of vision would be very useful.
Am I saying anything that is out of sync with where you are?
MR. RILEY: No.
DR. DETMER: If you are talking about that global outlook, I agree.
MR. RILEY: That is where you are operating from. I think probably the most useful deliverable would be to take the papers that we have identified from the United Kingdom and Canada and Australia and what they call the DII master plan here, and to integrate those documents into an NHII master plan or strategic plan, or whatever you want to call it.
DR. DETMER: Which in a way is almost a GHII, really.
MR. RILEY: Yes, at that point it does become that. Then you have got the intergalactic information network. But we are not there yet.
DR. DETMER: I think that would be extremely useful to us.
MR. RILEY: I will try, but I am not for sure I can get that done before the next meeting.
DR. DETMER: Even if you can just get an outline, just the skeletal kind of architectural outline for it, that would be useful. That sort of gives a sense of the boundaries of this.
MR. RILEY: Yes, right.
DR. DETMER: Then I guess about the only thing that we really didn't have much time to cover was sort of the population dimension of that.
The beauty of the DOD, it has to worry about populations. So, I am sure you have been doing that very much.
MR. RILEY: Yes, that is the way the service member life cycle, I was going to draw that up, but we kind of ran out of time. I can draw that out for you after we break up, if you like.
DR. DETMER: If you can flesh out a little of that, too, then as far as I am concerned, I found this very useful.
I think once we get our own presentations on the other systems done, then I think you also, if we are really talking about it in a global way, ultimately you will also want to talk about optimization, how do you create more value for a dollar issues, aside from those that just fall out because you are more organized.
MR. RILEY: Right.
DR. DETMER: How do you also start looking for quality measures and some of those issues, let alone preventive services, and health education.
MR. RILEY: Our population stuff for DOD is called force health protection. It was mandated by the President last year.
I couldn't get the agreement to move forward on that. We built a bunch of the models and did what we had to do, but because of political reasons inside the three services, I couldn't get that to move forward.
I worked with some folks over in the White House and basically Clinton, in a speech last October, I believe it was, mandated force health protection. So, they have a Presidential Directive to do that, and they are on the hook to do that, so they are moving forward with it finally.
We will get there one way or the other. Kicking and screaming, we are going to get them there.
DR. DETMER: I wanted to leave a few minutes. We wanted to adjourn in about five, seven minutes, but I wanted to leave a few minutes for us to tidy up any other loose ends, although your summary was so good, I don't know that there is much more we need to do. If not, we can continue just talking our time out this morning.
DR. DEERING: I had only one very small item, which was I think somebody's recommendation. I had prepared draft unofficial notes from our brief meeting back in November.
I have never had any feedback on them, but since they are the only thing that we have that constitutes minutes, we need like a drop dead date to either hear any comments or changes, or not hear any comments and changes, and then put them into the record.
DR. DETMER: I wasn't there, so I can't provide you with comments.
DR. STARFIELD: Was the date for the next meeting set yesterday or not?
DR. DETMER: We are going to be talking about that this afternoon. It is going to be at the time of our next full committee meeting.
MS. GREENBERG: But it is conflicting with some other -- we will have to look. That is always the case.
DR. DEERING: I have only one sort of meta conceptual issue to raise. It harks back to our discussions yesterday and I think you even made this comment.
It is the assumption that, if it is not a driving force, it is at least a direction of drive toward the individual.
We also discussed extra-plan health and medical, and I separate those two specifically.
If, indeed, we feel that those are concerns that will influence the shape of things to come, how can we address those within this approach.
MR. RILEY: That is a very good question. My goal is to create the fertile ground for what I call an e health business ecosystem to develop.
I have stolen the term from electronic commerce, or e commerce, that IBM uses. I think they have actually trademarked the term, e commerce.
If you take the concepts of e commerce and the concept of business ecosystems and bring them together, you basically have an electronic ecosystem.
If you apply that to the health care domain, then that is where I come with this e health ecosystem, or whatever you want to call it, e health system.
Within that, if you are focused on this idea here, of convergence of computers, communications and content to create collaborative communities to convey care, what you will see, if you can set the standards, some basic standards in these areas, you can encourage solutions providers to develop fairly quickly solutions that meet specific business needs.
We already see that, in a kind of a haphazard fashion in terms of some of these sites that we are seeing develop that have you come on and you can store your personal record or health risk appraisal type of data on line, or you can get a copy of it and print it out or what have you.
Those are just the beginnings. I think if you burn a forest and you watch how the forest recovers over time, there are certain plants that come in first that are there.
Once they are in place and have a toe hold, then other plants begin to sprout and flora and fauna come back.
If you watch that ecological recovery process, you can apply some of those principles to this particular area that we are talking about.
I think I talked yesterday about five, but there are only four stages to these ecosystems that have been defined for the business world.
Each of those has a major driving factor behind it. You can look at the maturity of a particular business system set of activities, from an economic point of view, and kind of place them on this continuum, whether they are in the start-up phase, whether they are mature, or in the die or renovate type phase.
I guess that is a kind of a long-winded -- I think I tried to build in a way to accommodate that. That doesn't mean that there won't be punctuated equilibria where you have a sudden shift in things.
Like the internet, for example, was a huge shift that most people didn't see coming. Certainly, Bill Gates didn't see it coming. His vision was the desk top.
Now, all of a sudden, you have got this really big, worldwide environment, and the internet is a major factor at the global level on that other page there, that enables these technologies.
DR. DETMER: Yes, it does still seem like however clever one can roll some of this forward, it does seem to me like you are still going to have some tension that will ultimately come down to policy decisions on how much, if you will.
One tension, for example, that I see is the issue of, in the privacy community, there is one set of privacy fundamentals that would really say, I don't want simply as a standard for national policy the right to be left alone.
I want the right to remain unknown, which allows me to opt in and out of any data base.
I don't know if that is going to functionally work as a requisite of citizenship in these kinds of things.
I think as a threshold if you did, in fact, institute with the security strategies the Brandeis threshold, which is the right to be left alone, I think that is a workable deal, from my point of view.
I don't think that the right to remain unknown, even aside from this issue, of just looking at the issue of communicable disease kinds of things, I think the culture itself has too much at stake to allow that to play out, aside from the data systems.
I think that unless some of those issues are policy decisions, as boundary conditions at a policy level, I don't think that is a technologic issue. I think that is a conceptual, cultural decision, and then you have got to have a mechanism where it can work out.
MR. RILEY: What is interesting about that is, this group has the ability to -- let's say there is a proposed policy change in one form or another.
Number one, is it technologically implementable. What are its implications on the technology infrastructure.
Or going back the other direction, if we see changes in technology that now enable something that we couldn't have done before policy-wise or what have you, that is why, when I was talking about that model, that I feel like this group is operating at that global level, in terms of being able to influence policy and setting the parameters of those boundaries that you were talking about. I think that is a very important role for the group.
The reason why you monitor all those other things is to be able to influence that, to set those boundaries, to help identify those.
Occasionally, you may get down into these lower areas and use your bully pulpit to knock out a log jam or to move something forward.
DR. DETMER: That is why I say, in any given year, you may have a different shift of, these are our priorities this year, and one of them may be fairly targeted, actually, a standard kind of issue.
That is also -- in a sense, we have got the standards work group. To some extent, that should all get done there.
If it goes up to the issue where it is clearly a more global policy question --
MR. RILEY: I mean, most likely the standards work group are focused at this level and this level, probably haven't even thought about this level yet, in terms of standards.
Maybe we write a paper that talks about, what are the major patterns at this level in terms of operating environments, things that would be helpful to people out there, that are trying to manage this stuff out in the facilities in the real world.
DR. DEERING: It also touches on something you had said from the beginning, about looking at the work of the other groups in light of the concept paper, to see what is missing.
For example, we learned yesterday that the privacy group really isn't looking at all at certain issues of internet-based access. It is just not in their purview.
The same may be true for standards. I haven't followed their work. It could be true of many other groups.
It would be sort of like a reminder system. You know, have you expanded your portfolio to include some of these issues that might not have been on the horizon when you first set yourself up.
MR. RILEY: That is why the strategy document or the master plan, or whatever you want to call it, becomes important, because then you can coordinate across the groups.
You have an agenda that you can set and partition the labor, if you will, across the groups.
DR. DETMER: This is kind of fascinating, when I look down at Sandy down here. Here is an agency that is talking about now starting to purchase on quality, not just pay bills.
That starts throwing a set of very important functional requirements into the thing. Unless you, again, reflect those against some of these questions and issues -- I think, as you guys move forward, having you folks work on that is great.
I think, to wrap this up for this meeting, I feel like we have actually come quite a ways. I think we clearly have been benefited by the people who come to the meetings.
I thank you very much; you clearly have been one of those.
It strikes me that we do have a fairly decent strategy and a work plan laid out. I think at this point we just need to see what comes back to us for our next iterations.
I would like to see us, perhaps at the end of that next meeting, try, if we can, to lay out a skeleton strategy for a work plan for the coming year.
I think we couldn't have done that today, in this meeting. We have moved a long way toward being able to do that at the end of business -- I would like to see that done, if we could, at the end of the business of our next meeting.
Now, it is possible we won't have enough time to do that, but it would be nice if we could. If not, if we don't finish it at the next meeting, we could maybe get it structured enough that we could do it following the meeting through interaction, rather than having to wait for yet another meeting to do it. Do you see what I am saying?
MS. GREENBERG: Yes.
DR. DETMER: What else am I missing? Are you pretty comfortable? How about others of you?
Okay, why don't we adjourn.
[Whereupon, at 11:33 a.m., the subcommittee meeting was adjourned.]