Please remove me from the mailing list Vikram Bharwada Director-Technology iSpan Technologies Ltd. Ph: +91 22 28507439
-----Original Message----- From: owner-openehr-techni...@openehr.org [mailto:owner-openehr-technical at openehr.org]On Behalf Of Christopher Feahr Sent: Wednesday, August 06, 2003 4:50 AM To: Thomas Clark; Thomas Beale; openehr-technical at openehr.org Subject: Re: certification and verification of OpenEHR Absolutely! I'm sure there are thousands of un-tapped pockets of technical brilliance out in our provider community... but most very busy with patients and, with the exception of nut-cases like myself, probably not THAT passionately interested in information technology. However, virtually all of these folks are experts with respect to the "business requirements" of medical management software... as are many of their office managers. We need a mutually agreeable methodology for "mining" this business knowledge, without taking up too much of their time. So the task is to construct a mechanism for proactively reaching out to a [self-registered] vetting pool of provider business experts around the world. We would build our straw-man models, requirements-lists, etc.... then decompose them (using special tooling) into discrete questions that make sense to the provider community... perhaps supplemented with diagrams and graphics that they would readily understand (without first attending UML Boot Camp)... and collect their structured responses into a database. Clearly, we will have to give some thought to (and find a source of funding for) the tool set I am describing. But at the end of the day, we should have a mechanism for formally vetting each section of our user-specific, functional model of health care processes. (This will also be a way, incidentally, to find those pockets of tech. brilliance, and to draw these "cursed" individuals further into the bottomless time-sink of "healthcare standards development". Based on my US-experience, I often say that "doctors won't attend SDO meetings". But I don't think that's entirely true. When we have an SDO that is focused squarely on the business needs of smaller providers... and doctors have gained an understanding of what is being discussed at SDO meetings... then I suspect that quite a few will be interested in a more active role. However, the SDO-labor-model needs to be changed too... so that fewer face-to-face meetings are necessary.) regards, -Chris Christopher J. Feahr, O.D. Optiserv Consulting (Vision Industry) Office: (707) 579-4984 Cell: (707) 529-2268 http://Optiserv.com http://VisionDataStandard.org ----- Original Message ----- From: "Thomas Clark" <tcl...@hcsystems.com> To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" <thomas at deepthought.com.au>; <openehr-technical at openehr.org> Sent: Tuesday, August 05, 2003 1:45 PM Subject: Re: certification and verification of OpenEHR > Hi Chris, > > Good comments. Don't hold back! > > Regarding Providers I must say that they surprise me at times. My primary > Physician obtained a degree in Electrical Engineering prior to his medical > degrees. He has modernized his internal medicine department proficiently. > > He could use some help on the records systems but I believe he has the > basics in-hand. Ask him and one might get a verbose response. > > -Thomas Clark > > > ----- Original Message ----- > From: "Christopher Feahr" <chris at optiserv.com> > To: <lakewood at copper.net>; "Thomas Beale" <thomas at deepthought.com.au>; > <openehr-technical at openehr.org> > Sent: Tuesday, August 05, 2003 1:05 PM > Subject: Re: certification and verification of OpenEHR > > > > Thomas, > > Thanks for the comments. My only caution about asking physicians to > > comment on the desirability of EHR-system proposals is that they may not > > understand [what we mean by] our questions... and we probably won't > > really understand [what they mean by] their responses. > > > > When we ask for input from practicing physicians, I would rather pose > > very discrete questions, such as: "When you do this procedure, our > > committee believes that these information components are absolutely > > necessary... do you agree?" > > > > Anyway... this has been a busy few days with all the activity in the HL7 > > EHR SIG, and I guess I was in a particularly verbose mode... even for > > me... yesterday! (I saw several "please remove me! messages posted > > today... I hope I didn't drive away any of your "regulars customers"!) > > > > Take care, > > -Chris > > > > Christopher J. Feahr, O.D. > > Optiserv Consulting (Vision Industry) > > Office: (707) 579-4984 > > Cell: (707) 529-2268 > > http //Optiserv.com > > http //VisionDataStandard.org > > ----- Original Message ----- > > From: <lakewood at copper.net> > > To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > Sent: Tuesday, August 05, 2003 9:24 AM > > Subject: Re: certification and verification of OpenEHR > > > > > > > Hi Chris, > > > > > > Great response! > > > > > > Would like to learn what the US Providers want and need from a system > > > like the proposed OpenEHR project. Contributors to the project are at > > > liberty to publish; but the remaining, quite numerous, Providers may > > well > > > be unaware of the existence of such projects and unable to respond. > > > > > > 'Pass the baton to the healthcare associations' seems appropriate. Why > > not > > > have them poll their members? > > > > > > Nothing like designing a system that a majority of the users reject. > > > > > > -Thomas Clark > > > > > > ----- Original Message ----- > > > From: "Christopher Feahr" <chris at optiserv.com> > > > To: "Thomas Clark" <tclark at hcsystems.com>; "Thomas Beale" > > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > > Sent: Monday, August 04, 2003 10:20 AM > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > Thomas, > > > > Thanks! And I hardly know where to begin responding... but I do > > like > > > > all of your comments. The thing about providers being considered "a > > > > homogeneous group of individuals working for the common good" is > > really > > > > a matter of philosophical and, perhaps, spiritual orientation. I > > agree > > > > that we (providers) do not always behave this admirably! But you > > are > > > > also DEAD ON with your comments suggesting that single-minded > > user-focus > > > > (on the user's OWN needs, as opposed to the needs of the greater > > > > healthcare community) is related to most users being permanently > > stuck > > > > in "survival mode". > > > > > > > > Businesses are struggling to survive... more and more BECAUSE of the > > > > escalating costs of driving the health care bus through the > > information > > > > quagmire. Insurance interests ARE taking more control over who does > > > > what in healthcare... but not [always!] out of a megalomaniacal > > interest > > > > in controlling providers... but mostly to get control of the COSTS > > that > > > > providers seem to be powerless to control themselves.... again, > > because > > > > providers have pathetic software... because no one can build the > > > > software they need... because we lack sufficient standards to give > > > > application developers sufficient confidence that doctors would > > actually > > > > buy the software if they did build it! > > > > > > > > We are not trying to decide whether breaking out of this > > death-spiral is > > > > a good idea. Our only task now is to decide HOW to break out of it. > > > > It's not sufficient to say that providers have what they deserve > > because > > > > they've refused to agree on something better (for their patients)... > > > > unless we first imagine and then create for them a mechanism whereby > > > > they CAN agree. Ideally, we should have one geo-politically neutral > > SDO > > > > maintaining robust communications with a solid, global network of > > > > medical subject matter experts. Then we build "straw man" > > > > model-components and run them through our expert vetting pool until > > no > > > > one has substantial objection. Eventually, these converge into a > > > > generally accepted model of the persons, places, things, actions, > > > > relationships, and data elements of healthcare... the aspects of > > these > > > > things that our distributed panel of experts agree are or should be > > > > "always true". > > > > > > > > There is much (about the process of CARE) that the industry can and > > will > > > > agree on. (much of this agreement already exists as "evidence based > > > > practice guidelines" or "standard of care"). We need a way to > > further > > > > formalize that agreement into a technical model of *core* healthcare > > > > processes and information. Then we can build on it. As > > > > healthcare-paradigms shift, we will have to absorb the shift into > > the > > > > model, just as practitioners will have to implement the shift in > > real > > > > care processes. Obviously, we require a model-technology that is > > > > flexible enough to be changed... but remember, this is a MODEL... of > > a > > > > REAL process. If the process can be changed (and society agree that > > is > > > > SHOULD change)... and that change impacts information management... > > then > > > > the world has no choice. We must change both the model and the real > > > > processes and the information structures and record architectures... > > to > > > > accommodate the better way of caring for people. > > > > > > > > We never want to change... yet we always do. The proponents of > > change > > > > always want it to go faster, but I am learning that rapid change > > ALWAYS > > > > causes unnecessary suffering within a system as brittle, fragmented, > > and > > > > interdependent as healthcare. The minute we stop kicking at it, > > > > however, it STOPS changing! So the collective "government" role is > > NOT > > > > to write regulations like HIPAA that foist a particular IT-paradigm > > onto > > > > 500,000 providers by a "deadline". The proper government role is to > > > > FUND the mechanism whereby provider (and other user) needs can be > > > > abstracted into a standard. Then... with a robust and RELIABLE > > > > standards floor beneath our feet, we let COMMON SENSE be the driver > > to > > > > build, purchase, and implement interoperable software. > > > > > > > > Christopher J. Feahr, O.D. > > > > Optiserv Consulting (Vision Industry) > > > > Office: (707) 579-4984 > > > > Cell: (707) 529-2268 > > > > http //Optiserv.com > > > > http //VisionDataStandard.org > > > > ----- Original Message ----- > > > > From: "Thomas Clark" <tclark at hcsystems.com> > > > > To: "Christopher Feahr" <chris at optiserv.com>; "Thomas Beale" > > > > <thomas at deepthought.com.au>; <openehr-technical at openehr.org> > > > > Sent: Sunday, August 03, 2003 12:50 PM > > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > > > > Hi All, > > > > > > > > > > I would like to add a big 'RIGHT-ON' to Christopher's > > contribution! > > > > > > > > > > >From the operations viewpoint cost is a major factor and when > > > > significant > > > > > precludes > > > > > participation by parties and organizations that should be > > involved. > > > > Also, > > > > > the healthcare > > > > > industry cannot be described as a homogeneous group of individuals > > > > working > > > > > for the > > > > > common good, and perhaps the Patient's health. > > > > > > > > > > What is noticeable is that different groups/disciplines rarely > > > > communicate > > > > > effectively > > > > > and are often at odds over even small matters with 'turf control' > > a > > > > common > > > > > factor. > > > > > > > > > > I recently attempted to get a handle on how county operations > > handle > > > > > everything from > > > > > budgets to HIPAA. Unfortunately even volunteers have a difficult > > time > > > > being > > > > > accepted > > > > > and integrated. What is noticeable is that they jealously guard > > their > > > > > current processes, > > > > > procedures and suppliers to the extent that modifications, > > upgrades > > > > and new > > > > > methods > > > > > and technologies are rejected. My suspicion is that they have > > learned > > > > this > > > > > behavior > > > > > simply because budget constraints and consecutive budget cuts have > > > > placed > > > > > them in a > > > > > primarily survival mode. > > > > > > > > > > Administrators are less friendly and politicians are notable for > > their > > > > lack > > > > > of commitment. > > > > > > > > > > The healthcare system is already 'locked' in a mode where even > > small > > > > > sections are > > > > > unable to modify and/or improve current operations. An expanding > > > > population > > > > > will > > > > > render this state of affairs defunct. > > > > > > > > > > My characterization of the healthcare industry is a group of > > > > > not-necessarily-connected > > > > > small universes within which specialties withdraw into > > semi-permeable > > > > > spheres in an > > > > > attempt to create another small universe. Imposing order in a > > > > > cost-efficient/effective > > > > > manor is likely to be rejected soon or very soon after > > introduction, > > > > i.e., > > > > > failure is a > > > > > sure bet. > > > > > > > > > > Occasionally bright stars appear but too often are > > teaching/research > > > > > personnel and > > > > > organizations. En masse the deficiency in Patient-centric care is > > > > having > > > > > major impacts > > > > > on public sentiment which in turn has a dark side. > > Patient-centered > > > > > healthcare is the > > > > > main target. > > > > > > > > > > HOW DOES OpenEHR FIT INTO THIS? > > > > > > > > > > It is a global healthcare industry that is of interest with > > regional > > > > and > > > > > local industries > > > > > playing major roles. Important are major factors covering > > healthcare > > > > > disciplines and > > > > > Patient specifics, e.g., cultural, ethnic, language, social, age, > > > > medical, > > > > > dental, mental > > > > > and work (certainly not an all-inclusive list). Within the five > > > > minutes > > > > > allocated per > > > > > Patient by an HMO try resolving some of these issues during an > > office > > > > visit > > > > > or, > > > > > perhaps, a visit to an Emergency Room. > > > > > > > > > > Before IT can approach and render a local design for a significant > > > > number of > > > > > these > > > > > issues there are important criteria, requirements, objectives, > > goals > > > > and > > > > > administrative > > > > > issues that need to be resolved positively. OpenEHR must be > > > > accommodating to > > > > > the > > > > > extent that global regions and a global industry can use it as a > > > > bridge and > > > > > transport. > > > > > It must be more than a simple record-keeping system; it must > > include > > > > content > > > > > management and communications capabilities. > > > > > > > > > > As a tourist with a medical condition from Chicago, traveling in > > Paris > > > > and > > > > > requiring > > > > > immediate medical attention my preference would be for a system > > that > > > > > supports > > > > > language translations and common record sub-formats that allow the > > > > attending > > > > > physician to diagnose the problem, attend to it and update Paris > > and > > > > Chicago > > > > > records. > > > > > > > > > > >From an IT viewpoint it is a pipeline that supports applications > > > > requiring > > > > > access, > > > > > filtering, data translation, communications (perhaps with another > > > > > Practitioner), > > > > > auditing, backup, anticipatory storage and all in real-time. > > > > > > > > > > An adaptable 'standard *information* model' with 'granular > > sub-models' > > > > is > > > > > necessary and can incorporate Practitioner, Patient and > > Administrator > > > > > components. Interoperability with existing and 'planned' systems > > is > > > > > necessary > > > > > as well. Merging one or more foreign data sources into a single > > data > > > > source > > > > > would be desirable in an integration effort. > > > > > > > > > > Quote (Chris): > > > > > 'We need to encourage providers to shift their focus from the > > > > *records* to > > > > > the elements of health care information' > > > > > > > > > > Practitioners need to look at how they use current records systems > > and > > > > how > > > > > multiple Practitioners interface on healthcare processes, > > procedure > > > > and > > > > > issues. > > > > > Medical errors occur too frequently when Patients are passed from > > one > > > > > group/Practitioner to another, e.g., a trip to the operating room > > > > involving > > > > > insufficient or incorrect information. > > > > > > > > > > GLOBAL SUPPORT SYSTEM > > > > > > > > > > This remain a tough nut to crack, a major problem involving > > different > > > > > social/ > > > > > economic/ethnic/political/insurance/access boundaries. It is not > > an > > > > > impossible > > > > > task since other industries function well today across the same > > > > boundaries. > > > > > > > > > > KNOWLEDGE-BASED SUPPORT > > > > > > > > > > Many repetitions of a process/procedure may be necessary/required > > > > (e.g., > > > > > policy/regulations). Many may not so constrained. Automatic > > > > Knowledge-based > > > > > processes and procedures can alleviate workloads and bottlenecks. > > > > > > > > > > When properly identified, processes and procedures included within > > an > > > > > OpenEHR record can significantly contribute to data mining and > > > > processing > > > > > that will support future evaluations and performance studies that > > > > could lead > > > > > to > > > > > further enhancements and modifications. > > > > > > > > > > Decision-support and feedback on past, current and planned > > processes > > > > and > > > > > procedures can support Practitioners as well evaluate them. It can > > > > also > > > > > benefit > > > > > Patients. > > > > > > > > > > RECORD ARCHITECTURE > > > > > > > > > > Chris's comments about: > > > > > 'centralized or distributed record architecture' > > > > > > > > > > are significant because: > > > > > 1)Patients are unique > > > > > 2)Patient healthcare is unique and may be affected in different > > ways > > > > by > > > > > applied > > > > > processes, procedures, medications, Practitioners > > > > > 3)There are considerably more Patients than models and exceptions > > are > > > > bound > > > > > to > > > > > kill the model quickly > > > > > 4)Healthcare evolves through research, application, experience and > > > > learning. > > > > > Such evolutionary processes should not be burdened with model > > > > modifications. > > > > > > > > > > My preference is for viewing a Patient's healthcare as an > > adaptable > > > > object > > > > > that > > > > > can inherit from ancestors and healthcare-related objects (e.g., > > > > disease, > > > > > ethnic, > > > > > cultural, social, mental, work, environmental). Embedded in this > > is > > > > OpenEHR > > > > > as much more than a record-based system. > > > > > > > > > > Regards! > > > > > > > > > > -Thomas Clark > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Christopher Feahr" <chris at optiserv.com> > > > > > To: "Thomas Beale" <thomas at deepthought.com.au>; > > > > > <openehr-technical at openehr.org> > > > > > Sent: Sunday, August 03, 2003 7:09 AM > > > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > > > > > > > Dear Group, > > > > > > I have just recently joined your listserve, and have been > > actively > > > > > > participating in the HL7 EHR ballot discussion for only a few > > weeks. > > > > > > During the four years prior to that, I had been swimming in the > > > > > > HIPAA-EDI ocean, trying to figure out how the operational costs > > for > > > > > > 450,000 smaller providers would ever be lowered under our > > > > transaction > > > > > > rule. The answer is, "they won't... costs will increase". While > > > > HIPAA > > > > > > is arguably "another story", but I believe that the failure of > > the > > > > > > transaction rule to be embraced by our fragmented US provider > > > > community > > > > > > is closely related to the elusive success of the "standard EHR" > > > > effort. > > > > > > I have the distinct sense that our global EHR conversation is > > much > > > > > > closer to the heart of The Beast for small providers than the > > HIPAA > > > > > > slugfest will ever be... and much more likely to bring sanity to > > > > > > providers lives. Hence, my keen interest in it. Nevertheless, > > I > > > > > > sense an implied constraint throughout most of the discussions I > > > > have > > > > > > listened to... caused I think, by the almost single-minded focus > > on > > > > the > > > > > > attributes of the information *container*, rather than on the > > health > > > > > > information, itself. > > > > > > > > > > > > Containers and container systems were certainly a major > > constraint > > > > in > > > > > > the days of paper, and most providers still seem to cling to > > that > > > > > > "primary repository" or "medical chart" model even after "going > > > > > > paperless"... as doctors like to say in the US. "EHR" > > discussions > > > > seem > > > > > > to presume that we are still constrained by an overwhelming need > > for > > > > a > > > > > > monolithic, physical record system that has to "live" > > somewhere... > > > > all > > > > > > in one piece. Constraining every enterprise system to the same > > > > physical > > > > > > record architecture is always denied as an ultimate objective of > > > > > > "EHR"... although that *would* be a path to a fairly high level > > of > > > > > > user-system interoperability... it's just that no one would > > agree to > > > > do > > > > > > it. > > > > > > > > > > > > EHR Dream #2 seems to be a Big-EMR-in-the-sky, with which all > > user > > > > > > systems could remain synchronized. Again, that would certainly > > lead > > > > us > > > > > > toward a useful level of interoperability, assuming that the > > most > > > > > > trustworthy entity (the U.S. govt.? United Nations?) agreed to > > > > maintain > > > > > > the repository-in-the-sky, to which over one million enterprise > > > > systems > > > > > > would have to be rigorously mapped. But even if that were > > reasonably > > > > > > implementable, it makes providers uncomfortable... the idea of > > their > > > > > > records being "stored" with millions of "foreign" records in > > some > > > > far > > > > > > off place (like India), rather than in the safety of their back > > > > rooms... > > > > > > or just down the street... or at least in the same state or > > county. > > > > > > Have we asked providers to sit down and *really* articulate > > these > > > > > > fears?? These are paper-tiger issues. > > > > > > > > > > > > Attempting to standardize PMS applications on a generic record > > > > format > > > > > > for each major care domain/setting is obviously pointless. > > Doctors > > > > and > > > > > > PMS vendors simply will not agree.. mainly because neither will > > even > > > > > > bother attending the standards meetings. (note how > > enthusiastically > > > > this > > > > > > community is embracing EDI under the federal mandate of > > HIPAA... > > > > and > > > > > > how compelling small provider demand currently is for > > EDI-enabled > > > > > > products. Lack of perceived demand is the main reason that > > small > > > > PMS > > > > > > vendors don't bother attending SDO meetings to learn how to > > build > > > > them). > > > > > > > > > > > > On the other hand, I believe that a standard *information* model > > for > > > > the > > > > > > entire industry, with granular sub-models developed for each > > care > > > > > > domain/setting... would not only be possible to create, but > > would > > > > pave > > > > > > the most direct road toward useful interoperability. I believe > > that > > > > PMS > > > > > > vendors would voluntarily respect such a standard... and would > > > > hugely > > > > > > appreciate the freedom to design whatever record architectures > > they > > > > > > wanted. > > > > > > > > > > > > Step #1 would be to develop a universal *process* model, by > > > > > > painstakingly abstracting the non-controversial requirements of > > > > > > published, evidence-based practice guidelines. That will be the > > > > "heavy > > > > > > lifting" and the part requiring documented and extensive vetting > > by > > > > > > practicing physicians and other stakeholders. From the process > > > > model, > > > > > > however, we should be able to spin off a universal information > > model > > > > for > > > > > > Healthcare. Who would choose not to conform to such a model? > > > > Providers > > > > > > will happily agree to execute care processes in almost exactly > > the > > > > same > > > > > > way... according to standard-of-care guidelines. And all > > > > > > machine-to-machine messaging would have to be concerned with is > > the > > > > use > > > > > > of standard information elements, defined by a standard XML > > schema, > > > > > > driven by the standard model. > > > > > > > > > > > > It seems to me that the thing most in need of standardizing > > across > > > > the > > > > > > healthcare industry, is the information that goes INTO [an > > almost > > > > > > uncountable # of] user-specific record formats. We need to > > > > encourage > > > > > > providers to shift their focus from the *records* to the > > elements of > > > > > > health care information. The goal is to have the right > > information > > > > > > elements in front of the right eyes just in time to support the > > > > > > execution of the right healthcare process. > > > > > > > > > > > > It should not matter what sort of centralized or distributed > > record > > > > > > architecture the information either came from or is headed > > toward. > > > > All > > > > > > you need is a *standard* registry connected to the user system > > that > > > > > > knows where to look for the information that the user is > > demanding. > > > > If > > > > > > that registry doesn't point directly to a repository containing > > the > > > > > > desired patient information, it could poll the other registries. > > We > > > > > > could have millions of fragmented/distributed and even > > duplicative > > > > > > repositories of health information, but only one registry is > > > > required... > > > > > > although a handful of standard registry services could also be > > > > supported > > > > > > without significant degradation in service. (Consider, for > > example, > > > > our > > > > > > DNS system and how smoothly the internet functions, despite the > > > > number > > > > > > of domain name registrars and DNS services that exist.) > > > > > > > > > > > > Has the group discussed this general approach? For a longer > > and, > > > > > > perhaps more organized dissertation, please see my article at > > > > > > http //visiondatastandard.org/draftstandard.html , along with a > > > > draft > > > > > > ISO report, providing some additional background. > > > > > > > > > > > > Thanks for listening! > > > > > > Best regards, > > > > > > -Chris > > > > > > > > > > > > Christopher J. Feahr, O.D. > > > > > > Optiserv Consulting (Vision Industry) > > > > > > Office: (707) 579-4984 > > > > > > Cell: (707) 529-2268 > > > > > > http //Optiserv.com > > > > > > http //VisionDataStandard.org > > > > > > ----- Original Message ----- > > > > > > From: "Thomas Beale" <thomas at deepthought.com.au> > > > > > > To: <openehr-technical at openehr.org> > > > > > > Sent: Saturday, August 02, 2003 4:33 PM > > > > > > Subject: Re: certification and verification of OpenEHR > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Thomas, > > > > > > > > > > > > > > lakewood at copper.net wrote: > > > > > > > > > > > > > > >Hi All, > > > > > > > > > > > > > > > >Been off looking at some operational considerations > > associated > > > > with > > > > > > > >supporting, maintaining and updating global EHRs. > > > > > > > > > > > > > > > What was your study to do with? Our analysis of possible EHR > > users > > > > is > > > > > > > that most people would use regional EHRs, i.e. EHRs which are > > > > embedded > > > > > > > in the healthcare network in which they normally live. Issues > > of > > > > > > > consent, privacy, security, as well as technical and clinical > > > > issues > > > > > > can > > > > > > > be determined in advance on a regional basis, and set up wiith > > > > > > > appropriate contracts. When such patients have a health > > problem > > > > > > outside > > > > > > > this jurisdiction, e.g on holiday overseas, and ad hoc > > requeest > > > > for > > > > > > > health data needs to be possible - where there will be no > > advance > > > > > > > contracts, security clearances etc. > > > > > > > > > > > > > > However, some patients are always on the move. Military, aid > > > > workers, > > > > > > > elite athletes, conference speakers, entertainers, airline > > staff > > > > and > > > > > > so > > > > > > > on. THey can routinely have a problem anywhere in the world. > > So > > > > their > > > > > > > EHR needs to be set up in a different way - probably served > > from a > > > > > > > secure webportal which the network of carers for that kind of > > > > person > > > > > > > will have secure access, also set up in advance. But these > > people > > > > can > > > > > > > also need medical help outside their routiine care network, > > and > > > > > > > communications of part of the EHR will again devolve to ad hoc > > > > > > requests > > > > > > > and replies, where security and privacy have to be worked out > > on > > > > the > > > > > > spot. > > > > > > > > > > > > > > >The following types of > > > > > > > >users were considered: > > > > > > > >1)CREATORS > > > > > > > >-individual, groups or organizations that must, or want to, > > > > generate > > > > > > new or > > > > > > > >updated EHRs > > > > > > > >2)REVIEWERS > > > > > > > >-overseers, peers and formal reviewers > > > > > > > > > > > > > > > can you define this role in more detail to do with EHRs? Do > > you > > > > mean > > > > > > > senior medical staff? > > > > > > > > > > > > > > >3)ADMINISTRATORS > > > > > > > >-Data management/processing > > > > > > > >4)CERTIFIERS > > > > > > > >-Handles tasks associated with correctness, e.g., prior to > > use or > > > > > > archiving > > > > > > > > > > > > > > > also this role > > > > > > > > > > > > > > >There has to be user toolkits, possibly with custom > > components, > > > > > > available > > > > > > > >for the EHRs, and perhaps many different implementations of > > EHRs. > > > > > > There must > > > > > > > >also be administrative (e.g., configuration management), > > > > > > > > > > > > > > > you will see that the basic of configuration management are in > > the > > > > > > > COmmon RM > > > > > > (http //www.openehr.org/Doc_html/Model/Reference/common_rm.htm) > > > > > > > > > > > > > > >QA (e.g., does it > > > > > > > >work), evaluation (e.g., workflow) > > > > > > > > > > > > > > > clinical workflow is a big area, and will most likely have its > > own > > > > > > > services, but very closely bound in with the EHR > > > > > > > > > > > > > > > and performance (e.g., does it take less > > > > > > > >time to perform a task using pen and paper?) tools to address > > > > related > > > > > > > >operations (note that the supporting networks and systems > > have > > > > been > > > > > > left > > > > > > > >out). > > > > > > > > > > > > > > > I think all of what you are saying relates to IT / software > > > > > > engineering > > > > > > > quality assurance measures? > > > > > > > > > > > > > > >What kind of tools? > > > > > > > >SUGGESTION: graphical, possibly remote access and possibly > > > > wireless > > > > > > enabled. > > > > > > > > > > > > > > > >WHY? Not everyone loves computers, scripting and software > > plus is > > > > > > willing to > > > > > > > >dedicate the time and energy to get some script to play > > right. > > > > > > > > > > > > > > > >OPINION: Would like to see a tool that can access/breakdown > > > > different > > > > > > types > > > > > > > >of EHRs, support information transfer and synthesis of > > additional > > > > > > records, > > > > > > > >even a modified EHR. > > > > > > > > > > > > > > > there are two approaches to this. One is where the source > > "EHR" > > > > > > systems > > > > > > > are legacy databases, and don't obey any models. THere are > > > > approaches > > > > > > to > > > > > > > getting data using archetypes to model it, but of course they > > are > > > > not > > > > > > > completely simple - most legacy databases have different, > > annoying > > > > > > > schemas....you have to extract the raw data, match columns and > > > > rows to > > > > > > > target structures, synthesis missing bits etc etc. > > > > > > > > > > > > > > The other approach is when we are talking about moving > > information > > > > > > > from/to EHR systems which obey openEHR or some other accepted > > > > standard > > > > > > > for which we can write interoperability software much more > > easily. > > > > > > Then > > > > > > > interoperability is largely a matter of archetypes. > > > > > > > > > > > > > > - thomas > > > > > > > > > > > > > > > > > > > > > - > > > > > > > If you have any questions about using this list, > > > > > > > please send a message to d.lloyd at openehr.org > > > > > > > > > > > > - > > > > > > If you have any questions about using this list, > > > > > > please send a message to d.lloyd at openehr.org > > > > > > > > > > > > > - > > > > If you have any questions about using this list, > > > > please send a message to d.lloyd at openehr.org > > > > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org -------------- next part -------------- A non-text attachment was scrubbed... Name: Vikram Bharwada.vcf Type: text/x-vcard Size: 637 bytes Desc: not available URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20020806/9340a3cc/attachment.vcf>
