On Sat, 2003-06-07 at 15:40, Richard Schilling wrote: > The problem consolidated models haven't addressed yet, however is the > increased complexity > of managing duplicate functionality and dataschema on several systems.
This is exactly what openEHR's archetypes can do. The schema does not have to match up on each system as long as there is a common communications format (think EDI). > I've found that the overall design and reliability can take care of > this issue of "missing data". Designating > a group of systems as the "core" system set alleviates the problem. > Among > the core systems you can assume that each system is available when > necessary, and if a > part of a record isn't available the user interface can notify the user > appropriately. It's no more > difficult than making sure your mainframe is available all the time. Your view is (apparently) within a system of some type? You seem to be making some assumption of control. If patients only ever went to elements of a single healthcare system for treatment then this would work. As soon as patients change physicians, travel across the nation or around the world you can no longer assume your "core". Since you cannot assume that, then how will your "system" ever determine that some bit of healthcare information even exists much less find it when needed? In a consolidated environment I (the patient) presents a unique identifier (let's say a URL) where my record is located. Now send that information to my record. The receiving system is responsible for the authorization/authentication process the data goes through to be placed into my record. > Having each system "own" a specific part of a patient record works much > better when designing > the system itself. You don't end up reproducing database schema and > functionality > on more than one system. I talked about this at JavaOne in 2002. But again....*only* when you have a mechanism of discovering and cataloging the location of all the pieces of my record. The consolidated approach only requires being able to send and receive information in some standard format......a PDF, a RTF, an archetype, XML file, etc. So the communication channel and the information types must match......sounds like the same issues that federated systems face with the exception of the missing (or worse, unknown) data problem. > I call the approach the "single supplier" system. If you can assume > that each computer delivers > data reliably (which you can), then it makes more sense to rely on > single suppliers of data for each part of a patient record. Again, you can only *assume* that when you are discussing a closed system. > > A federated system could also lead to better control of patient > information by the patient, making HIPAA enthusiasts happy ;-) How does having my information scattered among several locations give me, the indivdual patient better control? Cheers, Tim
