On Jul 29, 2006, at 3:35 PM, Chris Richardson wrote:
OK, Reply is below in braces [];
----- Original Message -----
Sent: Saturday, July 29, 2006 2:38 PM
Subject: Re: [Hardhats-members] So what is an EHR architecture, anyway?
On Jul 29, 2006, at 12:24 PM, Chris Richardson wrote:
OK, I'll bite.
Thanks.
EHR architecture, A record architecture which helps to maintain the medical life history of an individual.
That sounds good. I might choose something less restrictive here, as the focus seems to be almost entirely longitudinal, a natural emphasis in an office environment, but I think there is more to an EHR architecture than that.
[You are partially correct, I did leave out the genetic components and the predictive nature of projection, but I am not sure we do that very well yet. As such, I put that into the extensibility aspect I mention later.]
Another major area of data sharing and interoperability not covered here is sharing data WITHIN an organization. For example, if I have both a primary cared provider and a specialist I see on a regular basis, then I would like the specialist to have access to the results of tests ordered by the primary care provider and vice versa (it's easier on my arm!)
Such an architecture should be dynamic and flexible
Flexible in what way?
[The medical record should be built with future change in mind. There is no predictive crystal ball which projects all of the enhancements that meical science will come up with or the magnitudes and scales of the data they will produce.
That's fine, but you're really talking about the "why" of flexibility, rather than the "what" or "how".
To wait for those wonderous enhancements just means that we loose so much important data as to the picture of general public health (the agregation of many of these records into a profile of the public health and the situations which bring us all to that state). Next, there needs to be the willingness to change to affect such change as to modify personal and public behavior to reduce the environmental health risks.]
Again, I agree with you. But isn't architecture the phase at which consider what it takes for us to realize our goals? We don't need to spell out all the technical details, of course, but a CONCEPT of how that flexibility might be attained is crucial.
enough to adapt to the changeing scal and density of medical data and also provide easy interchange with other data repositories.
Okay, this good. How would you define scale and density in this context?
[That would be predictive.
Hmm...? What would be predictive? In what sense?
Simple design rules need to be established that allow for expansion without forcing our own prejudice into the model.
I agree with you here (though I think it could be phrased in a more value-neutral way). Well, wait....I'm not so sure. It may well be an open question whether design rules are sufficient to attain what you describe. After all, design deals with concrete specifications, and the goal you describe really exists at a higher level of abstraction. Something to think about.
We do not know the challenges that the next turn of the cycle will bring. Standing still is not an option. In order to make meaningful decisions we need information from this time and space in as readble and accessible form as possible (non-paper).
These are all good thoughts, but they are really goals and design principles. At a minimum, I think an architecture needs to point the way to the mechanisms through which those goals might be achieved.
Standardization is the soul of that interchange, but is not held slavishly to only those standards.
Okay, this is your most radical statement yet, and I don't think it's quite clear what you mean. You can't have it both ways: either you meet the requirements of a standard or you don't. If what you mean is that standards shouldn't be the driver in determining the basic architecture of an EHR, then I agree. But if you mean that standards are useful, but we should feel free to deviate from them when they prove inconvenient, then I most assuredly do not agree.
[Actually, you can have it both ways. Standards are important, but they are only good for the general case. Take a look at the Kernel programs, they break the standards in a variety of ways in order to provide the flexibility to offer the functionality of the underlying platform to the application without forcing the applications to adapt to those specific platform specializations.]
Actually, I think you example says more about problems with our current coding standards than anything else.If I were writing the SAC today, I would not classify Kernel as an application, but as infrastructure. The fact that the SAC is littered with parenthetical notes saying "(Exemption: Kernel)" is an indication that the SAC fails to make a distinction that it should make.
It needs to be extensible,
I agree. And sadly, this is one of the areas real systems most often fall short.
expansive,
Expansive? In what sense?
[Specialist groups have different measures which are not necessarily familiar to the general physician. The EHR should be able to record such specialist information in such a way that would be meaningful to another specialist in that field. Again, if we do not provide an extensible framework to adapt to the emerging technologies, their efforts would be meaningless. By the same token, the absence of such records for a person who has never been seen by such a specialist, should not be hampered, nor block a future encounter.]
Is it your intent here to draw a distinction between extensibility as an architectural principle and the reason that extensibility is needed in the EHR?
secure (as in private),
I don't know if this is your intent, but I wouldn't limit security in this sense. If anything, I would emphasize that security includes privacy.
and contain consistency checks to insure that the record is only changed by authorized individuals.
That's part of security, too.
[Which is why I included it.]
How is that, Greg?
Authorization and authentication are not the same. Authentication has to do with determining whether you are who you claim to be, and authorization has to do with determining whether or not an authenticated user is allowed to take a selected action. In Kernel, access and verify codes are a mechanism for authentication, security keys are one mechanism used for authorization. But neither is the same as encryption or other mechanisms used to keep data private, nor is it the same as hashes or electronic signatures or other mechanisms used to maintain integrity and establish that a person really did take an action he or she claims to have taken or not taken (non-repudiability).
Not bad. I think my concept of architecture is a little more concrete and a little less programmatic, but the whole point of the question was to solicit other people's ideas as to what architecture means. I appreciate your response.
[You can provide a framework, but as soon as you put limits on the structure, you will be defeated.
Limits on the structure of what? If you think I am suggesting we legislate a specific design, you have missed my point.
This is one of the reasons that Biology mirrors reality and works so well and people are so bad at predicting the boundaries.]
Gregory Woodhouse
"You can't win if you don't finish the race."
--Richard Petty
[...and if you don't play, you can't win. -- me]
Very true.
