Clinical Practice Guidelines and Queries - Customized Health Maintenance

Table of Contents

• Introduction
• Definitions
• The Approach Based on Template Technology
• Two Erroneous Premises Underlining Templates and Queries
• Retrospective Queries are Prospective Queries in Disguise
• The Solution: The Praxis Clinical Practice Guidelines and Queries
• The Praxis Agent
• Anatomy of a Clinical Practice Guideline (CPG)
• Handling of the CPG Message
• Tabulation of User Response: The Prospective Query
• CPG Trigger versus Activation
• What about Prospective Queries?
• Reporting On CPG's And Queries
• Improving the Practice of Medicine
• Different Guides for Different Folks!
• The Handling of Retrospective Queries - The SUNY Interoperability Engine
• Ontological Translation: The SUNY Approach for EMR Interoperabilty
• Doctor Werner Ceusters
• Conclusion

Introduction

Praxis Electronic Medical Records (EMR), based on the unique technology called Concept Processing, released a fundamentally new and far-reaching approach to the management of Clinical Practice Guidelines and Queries. We present a far superior Clinical Guidelines and Queries than those found in template-based systems. This technical paper outlines the limitations of the current template approach for both Clinical Practice Guidelines, Queries, and Interoperabilty, and describes this alternative new technology we believe will revolutionize the practice of medicine.

Definitions

Clinical Practice Guidelines (CPGs) are any rules that a provider uses when determining diagnostic tests and treatment plans for individual patients. Although CPGs can be either formal or informal, and either internal or external to the provider, they are most commonly viewed as recommendations directed to the provider by external agencies. In the Electronic Medical Record environment, they involve text messages presented in a variety of ways.

Queries are searches performed on electronic medical records. In healthcare, queries are designed to obtain information on diagnostic or treatment aspects of patient care. A query can be used to search for a variety of documented information. It can be directed to the Subjective area, the Objective area, the Assessment area and the Plan area. It can pertain to a diagnostic test order, a report based on an order, or the result of a test. Said results can be compared numerically against the laboratory reference range or a nationally set target. Queries can also determine non-clinical aspects of care, such as the number of patients seen by a provider during each clinic session. They can be provider-specific, clinic-specific, diagnosis-specific and patient-specific. They should always have quantifiable results, and the elements of each one should be carefully chosen to extract the required information in the most efficient and accurate possible way. Queries carried out on paper-based charts can be mirrored by queries carried out on Electronic Medical Records, although those carried out on EMRs would be more accurate, reliable and replicable while at the same time less time-consuming, error-prone and costly.

Retrospective Queries are well known to most physicians. They retrieve specified clinical and non-clinical information from previously entered medical records, and can be performed by a software program designed specifically for the Electronic Medical Record that is being queried.

Prospective Queries are questions sent to the healthcare provider so as to receive feedback in the future, after the event in question has taken place. They are the computerized counterparts of the well-known prospective clinical studies. They are difficult to perform using a paper-based approach because they require an appropriate alert at the point of care so that the information can be elicited by the provider and charted. Prospective Queries are easier to perform using a networked computerized approach that makes the written material instantly available in all relevant locations.

Templates: A template is a fixed structured text that is embedded in the EMR, and that forces a practitioner to choose among options or pick lists within it. It is presumably written by "experts" who have figured out a-priori the common symptoms, findings, and diagnoses within a given specialty. This text in general is difficult to change, as it does not learn with use.

Structured or Discrete Language is a set of preset medical words or phrases embedded in templates that are codified so that one may theoretically be able to query them retrospectively, and be able to transfer them across different Electronic Medical Records. As explained in this paper, this scheme is not effective. We believe it will be harmful to the practice of medicine because is limits the ability to dataentry the way the provider wants, and will result in spurious results as few doctors will take the time and effort to required to comply.

At issue now is how the methodology that has been developed for paper-based medical records and research should be adapted for use in the emerging Electronic Medical Record environment.

The Approach Based on Template Technology

The view held by the medical software industry is based on three major assumptions. First, if doctors are forced to manage data within the confines of templates, and thereby told exactly what to do under various clinical conditions, then the quality of the medical practice will automatically improve. Second, if doctors are forced to enter information in a predictable and controlled manner using structured or discrete language built into the software program, then effective retrospective queries can be performed to learn about the quality of the physician's practice. Third, if all clinical documents are entered using this structured language, then EMRs will be compatible across the board and medical records could easily flow from one provider to the next (interoperability). An alternative view holds that each patient will have his her own electronic records and that providers would receive information from that source.

What other experts have concluded, however, is that all of these assumptions are false. Instead of being rooted in accredited and well-founded scientific studies, these perceptions are the result of the software industry's investment in template technology. The "studies" performed thus far have been termed by Harris et al as "quasi-experimental" ([i]); they do not meet the requirements of rigorous scientific reasoning and they will not result in the a priori improvement in the quality of care, or in the application of appropriate queries. David J. Rothwell, MD, Richard Wheeler, MD, and Ngô Thanh Nhàn, Ph.D. have developed a far superior methodology for retrospective queries that we will describe here briefly. Ceusters' et al, of SUNY University, have also developed an alternative and more rational approach to interoperability, that we will describe here as well.

Two Erroneous Premises Underlining Templates and Queries

The use of templates to structure Clinical Practice Guidelines and retrospective queries is based on two premises:

The first premise says: "There is only ONE correct way to practice medicine, and everyone should do it exactly the same way." Following this line of reasoning, the use of perfect templates would result in the perfect practice of medicine. However, this is far from reality. The practice of medicine is as much of an art as it is a science and that no two doctors practice medicine the same way. Each doctor has his/her own methodology that is deeply steeped in diverse personal experiences and knowledge. Furthermore, with the use of templates, physicians would be relegated to the role of technicians following a predetermined script to diagnose and treat any presenting condition. However, Doctors are independent thinkers whose judgment is based on years of learning, personal values, and thoughts. For this alone, this approach is doomed to failure.

The second premise says: "The documentation that results from clicking on structured pick lists of options within templates represents an accurate and complete description of what actually takes place in the examining room, within the patient, and within the mind of the provider."

Yet, no evidence exists that what is actually happening in the examining room is accurately and completely reflected in the record. The template manufacturer's proposed solution is the "structured" or "codified" language approach. In this case, the template forces the provider to choose from a myriad of pick lists, each representing options that are coded so they can be queried later. Of course, if the option is not there, or cannot be found under the pressure of the office visit, or if, for whatever reason, selecting it does not occur to the provider, then of course, the application of a query would also be meaningless. In fact, the more tedious and difficult it is to fill out these complex pick-lists, the more unlikely it is that it will accurately reflect actual conditions. So this second premise also appears false.

And if either of these premises mentioned are false, then the whole edifice of using templates to impart Clinical Practice Guidelines and obtain effective retrospective queries falls apart like a house of cards.

Perhaps the failure to adopt an EMR has less to do with physician phobia to new technology—as has been maintained by the software industry for quite a while—than it does with the immediate realization by most doctors of the implications of these misguided approaches.

Unfortunately, the use of the computer to provide templates and structured language tends to limit the freedom of healthcare providers, rather than to liberate or empower them. The healthcare industry's attempt to use the computer to constrain its users lies in direct contradiction with how the computer has been used to enhance productivity and freedom of expression in most other scientific and technical fields. It seems to us that this use of templates demonstrates a failure to grasp what medicine is all about.

If this template approach were to become successful, physicians would be subjected to an electronic "big brother" that would constantly tell each provider exactly what to do, how to communicate, and how to report back. The doctor would simply be a medical terminology translator, with the entire clinical process carried out by the template. This does not fit the reality of clinical practice now or in the future.

Retrospective Queries are Prospective Queries in Disguise

What may not be obvious is that behind every retrospective query, there was a software engineer that created all the fields to be applied retrospectively. In other words, whatever the engineer has failed to incorporate prospectively cannot be performed retrospectively at all. Following this line of reasoning, to create a truly useful retrospective query, the software engineer would be required to know medicine better than the practicing physicians and the researchers combined. In fact, the developer would need to be omniscient. This also means that the creation of appropriate prospective queries in Electronic Medical Records becomes in time effective retrospective queries. Every retrospective query is really a prospective query in disguise.

Even if the clinical fields have been set up properly, any query of the required clinical finding may force the user to provide an answer at the point of care, every single time. In effect, as one deals with more specific clinical parameters, the requirements on the providers to comply are greater, and the barriers of using templates become insurmountable.

Inverse relationship between the ability to query retrospectively and the program users' freedom of expression. For high "queribility," the freedom of the user approaches zero.

The burdensome cost to providers to ensure precise and efficient data entry is a crucial impediment to the templated approach. In other words, the doctor is required to search through numerous pick-lists, just to find those options that accurately express the clinical reality in question. His or her ideas would not be searchable unless placed in a very structured language that would take prohibitively long to construct.

No one seems to have taken into account this cost at the point of care. This complication can be easily grasped when considering ICD-10's and CPTs, which are primitive in comparison to what is envisioned here, yet take so much of a provider's critical time and effort.

As is also the case with paper-based medical records, it is from the prospective query that far better information may be obtained with an EMR.

The Solution: The Praxis Clinical Practice Guidelines and Queries

At issue is how to combine the need to express medical writing unhampered, with the need to receive appropriate and timely information regarding Clinical Practice Guidelines, and how to then query freely created medical records so that the compliance to these guidelines can be carefully measured both by the clinic and by third parties. Finally, how to interface a freely engendered clinical text like the one in Praxis to other Health Information Systems and both transmit and receive clinical information.

After 20 years of work with this unique Concept Processing technology, realizing the importance of these issues from the outset, we have developed an elegant solution that we present to you here: This is a solution we believe satisfies these requirements far better and more elegantly than any template approach.

The Praxis Agent

Agents in Praxis are an offshoot of the Concept Processing technology shown in our Praxis demo, which you can download from www.praxisemr.com/demo

An agent can be thought of as an electronic message similar to emails we send to each other. However, unlike a simple email, agents are "intelligent" in the sense that they know when and how to show their message, and to whom. Most importantly, as it is the case with the other elements of Praxis, the agent is linked via the concept processing engine with the rest of the case by linking it with the encounter's assessment. This permits Praxis to learn from the provider's previous cases so that the agents will be released on the doctor's behalf only when needed and will do exactly what you have programmed them to do under similar circumstances. This is why we say that an agent is an "intelligent" message.

Agents are intelligent messages that not only carry information, but also know when and how to present themselves to the intended reader

The most important part of Agents, however, is that they are a linked to the assessement that sets them off. Thus once learned for a patient and a given condition, they automatically appear on a different patient with the same condition. They become ambassadors of the doctor's mind.

For a deeper discussion of Praxis agents, please see:

www.praxisemr.com/demo

Anatomy of a Clinical Practice Guideline (CPG)

The Clinical Practice Guideline agent is a variant of these messages that is not linked to an assessment or a given patient, but to a set of conditions that the clinic director sets up. They may also be imported from outside the clinic to be used within Praxis.

CPG agents may be easily programmed to activate only under certain conditions, such as at given time in the future, with certain periodicity, and when a given type of user comes into contact with a given type of patient. When we say a "given type of patient" we mean a patient that presents with a particular set of:

• Demographic criteria such as age, gender, insurance, and clinic defined
• Results of laboratory data
• Results of Vital Sign or Clinical parameter information
• Medications taken
• ICD-10's
• CPT's

...or any combination of the above. Only if a given patient meets these criteria, and interacts with the preset user will the intended guideline make its appearance.

An agent may be set to trigger when for patient with a specific ICD10 condition or a lab finding presents in front of the first cardiologist of a the multi-specialty clinic. Other users or providers will not see it.

Handling of the CPG Message

Color Alert indicates that a Clinical Practice Guideline agent has appeared for this patient. If the doctor clicks on the message, the full agent detailing relevant practice guidelines or queries immediately shows up.

After selecting the de-highlighted text message in the figure above or clicking the CPG button, the following window appears.

Line Item Clinical Practice Guidelines: Right clicking on each results in acceptance, refusal, or postponement.

The message received is not simply passive text. It is a call for action. As may be seen from the previous figure, the CPG agent is made up of line items of recommendations or requests (queries), each has independent periodicity, and demands independent response.

The response may be one of the following

• Ignore the request
• Accept the recommendation via a click of the mouse: The related text is then automatically pasted in the patient record indicating compliance.
• Reply that the recommendation was carried out in the recent past and therefore should not be performed now (placing the previous date). This response not only noted for query but also, the timers are reset. If the recommendation was a yearly referral, and this took place three months ago, the agent will trigger again in 9 months.
• Indicate that this recommendation is not indicated, and optionally enter the reason. The reason is recalled for future patients with this condition via the Concept Processor, saving the doctor time and effort in replying the same thing in the future.

Note that the message is not limited to a simple instruction or recommendation. It could be request a response a question, i.e. becomes a prospective query.

Tabulation of User Response: The Prospective Query

The responses are instantly tabulated, and queries on the clinic population can be automatically carried out.

CPG Trigger versus Activation

Notice that the CPG is triggered for a certain patient without a need for the patient to be seen by anyone. Of course, this means that no provider will actually see the message, but the fact that the agent was triggered is available to the query engine of the clinic. This immediately provides the clinics with crucial information.

Alternative 1. Agent was triggered, patient did not come to the clinic: The list of patients that require a given test, procedure or recommendation at any given date, but who have not come to the clinic can be automatically tabulated. The information can be exported and letters can be sent.

Alternative 2. Item Ignored: The provider may ignore a given recommendation or even the entire agent. When exiting the record, the provider will again be reminded that there are CPGs that have not yet been reviewed for this case. If the provider persists in taking no further action, this information is tabulated as not reviewed. At any point after the visit, one may find out what patients, what CPG's, what providers, have not been compliant and instantly find the actual encounter note for each entry with a click of the mouse.

Alternative 3. Acceptance: The provider views the agent and follows the recommendation. The agent may enter the actual text on the note avoiding needless typing by the provider. The date of performance will be noted for future query. This will reset the timers on the agent so that the next recommendation will appear with the needed periodicity. This information is also sent back for statistical purposes and the chart is marked as in the previous two cases. Note that it is immaterial what kind of text we are dealing with or what kind of an issue one queries (history, physical finding, lab order, procedure, instructions to patients)...it can be queried later no matter what.

Of great significance is the habit changing property of the Concept Processor. The next time the provider sees a similar case, Praxis instantly changes the provider's habit following the latest Clinical Practice recommendation accepted previously. Since old habits are the biggest obstacles to providing good patient care, this approach represents a major clinical breakthrough.

The most interesting result, however, is the last one:

Alternative 4. Rejection: The provider does not agree with performing the item because...

1. ...This item has already been done elsewhere or earlier in this clinic and not recorded in the CPG
   
   Or
   
   
2. ...In the view of the user, the item is not relevant to this patient at this time.
   
   

In the latter case, the provider has the opportunity to state the reason for not complying on the CPG itself, and the entered reply is tabulated with the query report. Furthermore, the same reply will be automatically submitted on behalf of the provider when encountering the same CPG under the same conditions. This saves precious physician time that would have been spent providing the same explanation repeatedly.

The consequences of this last option cannot be underestimated:

(1) If the provider is mistaken, he or she may be educated by the expert, thereby improving the doctor's approach for the better of all future cases.

(2) If the guideline itself was vague or inaccurate, and therefore difficult for the provider to understand, the CPG text can now be improved by the expert for future use thus improving compliance. The process results in more clearly expressed CPGs, that will be understood by more providers and is, therefore, superior to the original.

(3) If the provider is correct in not having followed the guideline for a particular condition or exception, then the expert may improve the guideline by taking into account the special circumstances that led the provider to ignore it, and thus improving the guideline as well.

The latter two options appear to be the most exciting in the quest to improve the practice of medicine. It is a given that most physicians wish to remain informed and practice the best medicine possible. However, in the final analysis it is up to the provider to understand the guidelines, agree with their recommendation, and comply with them as he or she sees fit. The use of the electronic agents allows this to happen while at the same time providing guideline makers precise, real-world feedback! Templates cannot do this nearly as well, if at all!

What about Prospective Queries?

Prospective queries are simply Clinical Practice Guidelines in reverse!

This is a fascinating concept. From a computational standpoint there is little difference between a Clinical Practice Guideline and a prospective query. Indeed, they represent exactly the same mechanism.

For example, the query may be a request for a given blood test for a patient with a particular ICD10 diagnosis. If the doctor complies, then the researcher will have the result of the blood test prospectively.

The Query may be a direct questions about symptoms and physical findings on certain types of patients. This insures, as in its paper counterpart, that the compliance is much greater. One thing is to search for records to find out which patients tell their physicians that they exercise at least once a day, something quite different is to prompt the provider to ask questions regarding physical exercise to certain type of patients while the patient is being interviewed by the provider. This is, of course, well known in medical research and gives prospective queries a clear advantage over retrospective queries. In fact, any kind of question regarding any kind of symptom or physical findings may be generated by a CPG agent and its answers are tabulated automatically in the same manner.

Reporting On CPG's And Queries

Now, the exciting part.

A simple report will disclose:

a.Between two dates, names of all patients whose practice guideline recommendations were triggered but who did not come to the clinic for a follow-up:

b.Between two dates, names of all patients whose CPGs were triggered and who came to the clinic but whose provider failed to abide by the CPG

1. Where the user did not look at there commendation
2. Where the user did look at the recommendation but felt that it was not relevant to that patient's condition (and the reason for not complying if entered by the user).
3. List of all the patients whose providers have complied with the recommendations.
4. The report includes in discrete fields the full name of all patients, registration number, age, full address and phone number and the name of the user whose CPG activated. This report may be exported to other systems for more sophisticated statistical analysis.
5. A direct link to audit actual visit note for any patient sampled

This also allows for mass mailings to all those patients that did not return for studies or therapies as recommended by the guidelines.

Improving the Practice of Medicine

Clinical Practice Guidelines are by nature created a priori. It is literally impossible to predict all the situations in which they will be applied. If practice guidelines were all-knowing then computers could practice medicine all by themselves. As this is not the case, absolute flexibility and compromise is imperative when critical information is communicated to clinicians. The template approach appears to be sufficiently flexible, but it does not encourage a provider to change his or habits, or to help improve the guideline. The agent technology, coupled with Concept Processing, will dramatically foster habit change and improve compliance. Yet, it will free physicians to practice their art in the best way they know how.

The agent technology coupled with concept processing will, in our opinion, revolutionize medicine by allowing a constant dialogue between providers and the makers of the guidelines. Because the query includes its own practice guideline, it means that every doctor should score 100% performance or have good excuses for not having this performance (i.e., The patient refused to come in, or the guideline was not indicated). This issue has been thoroughly expounded upon by Clayton Reynolds, MD on his paper the three R's for quality improvement:

The Three R's of Healthcare Quality

Different Guides for Different Folks!

All guidelines are relative and their scope is temporary. Thus, we do not agree with the proposal to hard-code them into templates. Praxis has the ability to help the guideline implementation process and its organic evolution as it is being used in the field. Analysis of the agent technology has led to the conclusion that guidelines are messages that can change and evolve just as medicine itself does. Clinical Practice Guidelines within agents, as we envision them, will present those messages right on cue, at the point of care, noiselessly and seamlessly.

Guidelines are not only constantly changing, but different entities often provide different guidelines for the same medical conditions. It is currently impossible for a provider to keep all of these slightly different approaches in mind for different patients.

These guidelines will be transmitted on the Internet to be read by all the Praxis systems in the world prior to acceptance by each Praxis EMR owner. Practice Guidelines and Queries currently in vogue can be easily translated - by the clinic - or by third parties - into Praxis CPG Agents that can be used at any Praxis using clinic.

The Concept Processor will recall different Clinical Practice Guidelines related to different insurers at the point of care. Agents can direct the provider to those guidelines and manage the interaction between the provider and the medical record, as well as between the provider and the Clinical Practice Guideline's architect.

Thus, a doctor will be able to subscribe to Clinical Practice Guidelines from many different sources, and the right agent will be applied under the right condition, as for example the patient's insurance.

The Handling of Retrospective Queries - The SUNY Interoperability Engine

Praxis' retrospective query EMR rivals any other in the market because Praxis is based on marked-up language, which means it can query all fielded clinical and demographic information plus standard clinical information such as procedures, diagnoses, CPT codes and medications. Certain pieces of retrospective data are not problematic: Demographic information such as the patient's age, insurance, gender, or city are all discrete fields that may often be queried accurately and easily in Praxis, as in all other EMRs today, because they are uniform in their recording method. In fact, for any combination of ICD10, CPT's, Demographic information, laboratory data, or vital signs/clinical parameters, Praxis is as effective as any other EMR in the market. At issue, however, is not what Praxis can or cannot do, but that retrospective queries are by their very nature unreliable beyond basic parameters such as demographic data, laboratories, vital signs, and medications, and CPT or ICD descriptors, and even within these parameters discrepancies can be found.

Some pieces of data require prospective development. For example, if the field for the "race" of the patient is not there, or if the completion of this field is not required for every incoming patient, then it becomes impossible to query for it later. In addition, every physician works with his or her own mental structure. These cannot imposed structures. These are a structure based on the experience and needs of each clinic and each physician. It is the basis of the art of medicine.

As we stated, the Concept Processor may appear to be "free text" but in fact, it is based on highly marked up language called "Extended Markup Language" or XML.

Short sample of the "Encounter Note" entered in the Praxis extended markup language (XML). Within this format, the chart "comes alive". Structured language can easily be added, although we hope that this never comes to pass.

Therefore we should explain that Praxis could effortlessly incorporate common structured vocabulary such as SNOMED® or MEDCINE® as part of its XML structure, just as it can query retrospectively much standard clinical data (ICD-10, CPTs, medications, procedures, etc).

If governmental regulations were to require the inclusion of these codes, the Concept Processor could include it as easily as a template system, by simply adding them to the current XML hidden structure within its new Knowledge Exchanger. In addition, new Natural Language parsers would help physicians translate this free text into codified language. Hopefully, clearer heads will prevail and this will never occur, as there is a far better way to accomplish queries. The most effective of these is to do so prospectively. The retrospective aspect of the query is a simply a semantic issue. If an agency wishes to retrospectively follow all patients that have green eyes, it can simply issue a clinical practice guideline, and from that point on, the system will insure that all patients with green eyes are being identified and therefore queried. The importance is not just that the researcher will accidentally find patients whose doctors described the eye coloration, but that it will prompt providers to think of this question when seeing patients and note it with a click of the mouse. In fact this is happening today requests that some agencies such as DOQIT have requested and are forcing templates makers to hard code it into their systems to give the illusion of a retrospective query. These are PROSPECTIVE requests for retrospective information. When using Electronic Medical Records, then every retrospective query is a prospective query in disguise. We contend that clinics can do a far better job at this than template makers.

Ontological Translation: The SUNY Approach for EMR Interoperabilty

After stating the above, there is an ingenious alternative solution to retrospective query and interoperability among disparate EMR Systems.

We are not alone in the belief that structured vocabulary alone will not effective in the performance of retrospective queries of Electronic Medical Records.

The New York State Center of Excellence in Bioinformatics & Life Sciences (SUNY) https://www.bioinformatics.buffalo.edu recently approached Praxis for a joint collaboration on this very issue, by using, not the standard discrete data template approach that the industry is promoting, but a more sophisticated approach based on the new field of Medical Ontology that they have developed.

The Center and Praxis have recently submitted a joint proposal to the NIH to underwrite the specific research that is being proposed by the Center to test their new interoperability engine.

https://org.buffalo.edu/RTU/indcollabs.html

Doctor Werner Ceusters

Doctor Werner Ceusters, the Director of the Ontological Research Group at the Center, is the man spearheading the Medical Ontology project. Doctor Ceusters has been involved in numerous national and European research projects in the area of Electronic Health Records, Natural Language Understanding and Ontology. Prior to coming to Buffalo, he was Executive Director of the European Center for Ontological Research at Saarland University, Germany, and is currently Professor in the Psychiatry Department of the School of Medicine and Biomedical Sciences, SUNY at Buffalo NY, Director of the Ontology Research Group of the New York State Center of Excellence in Bioinformatics and Life Sciences, and coordinator of Bioinformatics for the Health Science Faculties at UB.

Ceusters, et al. described the Cassandra syntactic-semantic tagging system in several brilliant papers that he has co-authored:

https://www.informatik.uni-trier.de/~ley/db/indices/a-tree/c/Ceusters:Werner.html).

The Cassandra system transforms sentences expressed in natural language into a structured representation that is independent of the subtleties of linguistic structure that underlies the way natural languages work. The structured representation eliminates sources of ambiguity thereby improving subsequent computational processing for information retrieval, automated translation and language understanding. Principles behind controlled language design and use are explained through a detailed study of the inconsistencies and ambiguities that arise when interpreting SNOMED procedure terms in the framework of medical information and it is shown that most of them can be explained as a violation of sound term-formation principles. The use of Cassandra in mediating between the two controlled of SNOMED and GALEN is described.

The Center's experience with the Cassandra syntax will relate the structure of a sentence to its meaning in ways that have proved to be successful. The syntax provides a tagging scheme that can be used in conjunction with the existing bracketing method to recapture lost information and to ensure correct coding of terms.

The Center's ultimate goal is to achieve a level of interoperability yet to be thought of by our competitors. Avoiding the weaknesses that exist in current mainstream plans for interoperability. Its work will make the Praxis EMR the leader in EMR interoperability.

In short, it is both the Center's and our view that current techniques for interoperability based solely on discrete language - besides being incredibly cumbersome and complex—will not really permit appropriate translations across different EMR platforms nor will they allow for any serious retrospective studies. The new ontological language developed by Doctor Ceusters at SUNY is separate from the actual text produced by providers but linked to it by logical and automatic means. It generates a meta text based on ontological language that will permit not only retrospective query of an effective kind but more importantly, effective interoperability across diverse EMR systems. Because Praxis is not restrained to templates, this engine will allow a far richer approach to interoperability not even conceived by the other template systems.

See the Interoperability paper

Conclusion

At the end of the Nineteenth Century, the entire world viewed the telegraph as the only way people would ever communicate across distances. Great frustration was expressed in the telegraph industry because after many years it had not been universally adopted, except by large companies and enterprises established specifically to this end.

Despite the strong resistance from people to learn Morse Code, there was much talk about putting a telegraph in every home, school, and office (Does all this sound familiar?). There was even discussion about teaching it in every school as a way to reduce this inborn resistance to the telegraph.

The whole communications industry, and great thinkers of the time were focused on building better and faster telegraph keys... all but one that is.

Alexander Graham Bell had a different idea. He had invented a contraption called "the telephone" that could, almost magically, transmit the human voice through a metal wire for miles! Many people did not believe their eyes or ears, and attempted to discover the "trick" when visiting Mr. Bell's stand at the various telegraph congresses around the US. Indeed, few grasped its practical utility, and no one paid much attention to his invention for about ten years.

People attending these telegraph conventions would repeatedly ask: "OK, but how do you plan to connect your fancy contraption to the telegraph?" In response, Bell would explain that there was no need for a telegraph when using the telephone. Still, his listeners were unsatisfied.

Finally, one investor agreed to work with Mr. Bell provided he could connect his phone to a Morse keyboard, and thus the American Telegraph and Telephone Company (AT&T) was born. Unsurprisingly, Mr. Bell never sold any telegraphs.

Can Praxis link to structured language programs? Yes it can, in the same way that the telephone could connect to the Morse keyboard. But let's hope it does not come to pass, for all doctors' sake!

Agent technology, coupled with the Concept Processor, will allow for rapid transmission of Clinical Practice Guidelines within a clinic, or across the world to any number of Praxis users. Using its agent technology, it will provide users with excellent guidelines at the point of care, and receive extremely accurate information regarding the care given. Indeed, the Reynolds approach of the three "R's, empowered by the Concept Processor, may be the key to the next revolution in Electronic Medical Records (See Clayton Reynolds, MD' paper on the three R's).

We contend that the use of CPG's within the Praxis electronic agents will be a far better approach than one based on the use of templates.

The Praxis team thanks Clayton Reynolds MD CM for his ideas and critiques. We also thank Ron Rudnicki, Business Process Analyst, and Werner Ceusters MD, of the Referent Tracking Unit of New York State Center of Excellence in Bioinformatics and Life Sciences (SUNY) for writing the part on the Ontologic Engine and the Cassandra Project.