Medical Guideline Expression in/with XML
ABSTRACT
Medical Guidelines become very important in healthcare, but they are big documents without context to the actual patient situation. xml-internet/intranet applications enable medical decisions, which strongly belong to the special patient-context.
Table of Contents
1. Requirements for Medical Guidelines
For increasing quality and efficiency in the healthcare market the introduction of medical guidelines is more and more in discussion. Medical guidelines are systematically developed statements to assist practitioner and patient decisions about appropriate health care for specific clinical circumstances [MUI 99].
Meanwhile there are a lot of official organizations [AWMF] [AEZQ] [BUT] in Germany, which take care of the development and maintenance of medical guidelines and the usage is a subject of the German law and healthcare government, because they believe in saving money and getting better treatment of the patients [CLA 01].
On the other hand side we know, that there is a great gap between the availability and the acceptance to work with guidelines. The main reasons therefore could be described as follow:
-
In Germany there are actually nearly about 800 guidelines, in some cases much more than one for a single disease, which results in confusion and doubtful quality.
-
Only 25% of the German practitioners are aware of medical guidelines [OLL 00].
-
Practitioners think that medical guidelines are controlling measures to reduce their therapeutically scope.
-
There are no incentives to work with medical guidelines.
-
There is no suitable integration in the daily routine.
-
Missing implementation in medical software products [ROL00].
Therefore an efficient implementation and integration of medical guidelines would mean:
-
To get the right information at the right time and place [NAI 95].
-
To get informations that strongly belongs to the context of the actual patient situation.
In MedWinnersSystem™, our webbased framework for practitioners, we have realized as one of the first companies an easy (online) integration of medical guidelines [NOE 00]in the medical patient record (Figure 1).
But after two years experience with our customers we saw that most of the practitioners have only about one minute in the case of patient treatment for waiting, reading, understanding and to act against a medical guideline and therefore need also:
-
Information in the concrete context of the patient data (e.g. diagnosis, prescription, laboratory results).
-
Scalable information from short devices, you can receive in seconds, up to more complex articles and study results.
-
Tools for statistical issues and data validation.
2. MEGAS — A framework for medical guidelines
2.1. Medical guideline application services
So we started to develop a centralized framework for the integration of medical guidelines on a medical guideline application services (MEGAS)server with defined communication and implementation interfaces using simple object access protocol (SOAP), extensible markup language (XML), common object model (COM) and other modern IT stuff (Figure 2).
2.2. Working on the client side
In our MedWinners client application we have implemented some trigger events: opening a patient record, changing diagnosis or prescription data of a patient or getting new laboratory results. In the case of a trigger event the local system creates a anonymous dataset of all actual patient parameters which is send via SOAP, Version 1.1 [BOX 00] as a standardized remote procedure call (RPC) protocol to the MEGAS server on a secure socket layer (SSL) connection.
The XML dataset contains information about age, sex, body weight and height, blood pressure, prescription data [GL], diagnosis [DIMDI], allergy, laboratory results [LOINC] and other interesting stuff about the patient. The patient and practitioner identification is packed into a 128-bit hash code at the client for security issues. This procedure enables secure communication also as anonymous re-identification of a patient and a practitioner for statistical purposes (courses, comparisons). In a second version we want also integrate the German protocol for the Health Professional Card (HPC) [GOE 00].
2.3. Server architecture
The MEGAS server receives the demand and validates in a first step the XML SOAP document against a schema. The server-side SOAP component has a generic COM interface, which makes it easily to develop and bind new guidelines and other medical rules to the MEGAS server. Actually we have about 40 different rules and guidelines for different purposes: guidelines for chronically heart failure, cardiac asthma and diabetes and many rules for checking the prescription data (e.g. contraindication, interactions, allergy, pregnancy) and others are still in progress. Because of the COMinterface the components can be written in different languages as JavaScript, XML with windows scripting host (WSH), visual basic (VB), Java or C++, so that also non-professional programmers could easily develop new rules and guidelines.
For each demand on the MEGAS server the database on the server produces an entry-record with a unique transaction number. Also each check of a rule produces a record, which belongs to the entry record. Because the demand and result information is put into XML blobs the system is easily extensible without changing the database (structure) [NOE 99].
Each single rule or medical guideline has an interface with predefined methods and functions. The main function is "check(XMLDom)", which causes the component to check the XMLdataset from the client and produce a XMLresult set, which could contain messages, references to literature or hyperlinks of study results, score points and (new) input parameters for missing information and parameters. For editing the persistent properties as standard values, higher and upper limits, scorepoints ranging from 0 up to 5 on a semi quantitative scale and the resulting messages out of a check run each component has a XML/webinterface for changing and editing. So in the case of a practitioner network the admin can modify the guidelines without any knowledge of programming and source code.
While running the check routines on each decision node they produce a score value. At least the score values are added together to an score index value, which is saved into the database for future measurements, statistics, which maybe in future influence the discussion of budgets between the practitioners or health networks and the insurance companies.
2.4. Displaying results and handle missing information
After checking all rules the results are added together to a single XML result document, which will be sent back to the client MedWinnersSystem™ application (SOAP-Response). The client application now can represent the results with extensible stylesheet language transformations (XSLT) in a browser window or save interesting information from the MEGAS server into a local database.
In practice it maybe a problem that inside the client application not all from the server requested information is collected and available. For example there is no input field and data storage for a special item or some information is invalid or pure missing. In that case the result set from the server could contain some input requests for missing information ("The blood pressure values are too old, please update the information: ___ / ___ mm HG"). If the missing information is entered it will be stored into the local system; so the next time the check is done the information maybe complete. Also it is possible to make directly a re-check with the actual information (Figure 3). We would prefer this way because by doing a re-check the information which is stored on the MEGAS server belongs to the initial transaction number of the first check. In future it maybe a interesting statistical question, how often this feature is used and how it change the quality of the score values. The main aspect is that the further development of the server architecture and the medical guidelines is independent of the client capabilities.
Each check needs only one or some seconds from client to server, validation on the server and the visualization of the results back on the client so that there is no acceptance problem because of performance.
3. Conclusions
Although MedWinnersSystem™ is actually the only medical software application, which has a MEGASintegration, a publication of the schemes and interfaces for other applications is intended after a period time and testing in a network with 400 practitioners in Germany. So we think that our work is a main basic research which will gain currency and extend the acceptance of working with medical guidelines in the direction of evidence based medicine (EBM) for medical decision support.
Acknowledgements
A special thanks to D. Albers and his team, M. Timpe, M. Hettlage and J. Langen, who helped develop this application and the supporting documents, to Prof. Dr. Dudeck for his engagement to establish XML in the German healthcare market and last but not least to Monika for her patience with me and my work.
Bibliography
Glossary
- COM
-
common object model
- EBM
-
evidence based medicine
- HPC
-
Health Professional Card
- MEGAS
-
medical guideline application services
- RPC
-
remote procedure call
- SOAP
-
simple object access protocol
- SSL
-
secure socket layer
- VB
-
visual basic
- WSH
-
windows scripting host
- XML
-
extensible markup language
- XSLT
-
extensible stylesheet language transformations


