> ------------Original Message------------ > From: Tim Cook <[EMAIL PROTECTED]> > To: "David Forslund" <[EMAIL PROTECTED]> > Cc: "OpenHealth List" <[EMAIL PROTECTED]> > Date: Fri, Oct-22-2004 1:11 PM > Subject: Re: Medical Record Location(s) was: Virtual Privacy Machine - reprise > > Hi David, > > How did I *know* I would hear from you on this subject? <vbg> > (BTW: we still need to write that paper)
Sure. Lets get on with it. I now have some time since I retired from LANL in July. > > On Fri, 2004-10-22 at 10:12, David Forslund wrote: > > I disagree. Your medical record can be created over a variety of > locations > > each of which may have its own id. This can occur even within a > single hospital > > system. Thus an MPI of some sort is required to "stitch" the medical > record together. > > > > > Allow me to add a bit more context here. > > MPI's are required where you have disparate applications within a > facility. I fully agree with those type of enterprise wide MPI's. > > It is very true that parts of my health record are created in various > places. For example; my family doctor recommends I go see a > cardiologist and she will send him a summary of the information he > needs. My cardiologist (if I had one) does what cardiologists do and > collects lots of data about my condition. At this point my family > doctor doesn't need or want all that data. She wants a summary of my > condition and the treatment plan. If for some reason she needs more > information she knows where to get it. The same applies to hospital > discharge summaries. > > This process / workflow remains the same irregardless the information > transfer media. It is appropriate, certain and efficient. > > The federated approach means you have to be able to guarantee that I > will have a unique identifier or trusted mapping between identifiers, > between my family doctor and any number of potential specialists that I > might be referred. Either of those two solutions is all the same just > the latter has an extra layer for errors to creep into and the former > is > an impossible administrative task. The federated approach doesn't mean that all the data has to be scattered. But rather, it can be scattered. There is nothing wrong with summary data being available with pointers to where the full data is (as you indicate above). Too much duplication of the data can be a big problem, too. > > The federated approach also means you must supply five nines or better > connectivity. My recommended approach means I can send data and if it > fails, retry later. There are still many many places in North America > where you can't guarantee connectivity across town much less between > towns. Of course. In my mind, an architecture should support federation but not require it. > > > > At any one point in time I have a unique patient identifier. > Because my > > > records are on file in Dr. Smith's office on Broadway in MyTown and > the > > > file number is 12345 I can have any pertinent information sent to > my > > > record. When I decide to switch to Dr. Jones on Main Street in > > > AnotherTown I can do so and still have a unique patient (record) > > > identifier.....just not the same one I had before. > > > > Exactly, but the records from both locations may need to be combined. > Thus > > the need for an MPI. > > No, they don't need to be combined. My original record can be > moved/copied or not, as I choose and whether the applications provide a > suitable means of import/export. I don't necessarily mean static combining, but rather dynamically linking the data or dynamically combining. Moving the data is ok, but moving it too much will reduce the quality of the data since features of the data known to the source may be lost. Copying is better, but then one has to make sure one knows where the original source of the data it to ensure that the copying doesn't compromise the data quality. > > The scenario above says I am changing PRIMARY care > physicians....meaning > there will still only be one primary care record. If a patient chooses > to visit more than one primary (more than one 'primary'?) care > physician > at a time then they are controlling the quality of their medical record > in a negative manner and simply should be advised as such. The > potential still exists for one physician to send summary data to the > other record if the patient wants. I think there are multiple PRIMARY care records unless one is careful to move or copy the PRIMARY record in the transition. Exchange of data or data integration may well be required. Our health system no longer requires a Primary Care Physician (PCP). So it is up to the patient to provide some integrating context. > > The technology exists to make large scale MPI implementations work. > What doesn't exist are the social, administrative and financial > capabilities. I agree that the technology is not the major limitation. Social is probably the biggest barrier. Closely associated with this is the lack of incentive to pay for an MPI, even though it ultimately might reduce costs because what is done now is administratively very expensive and costly. People end up duplicating the capability of an MPI at great expense. Dave > > Regards, > Tim > > >
