DrawML and SVG   Table of contents   Indexes   Information and Content Exchange
 

Electronic health care record transfer
, Development of an XML EHCR transfer message
 Andrew J   Hinchley
  Managing Consultant
  Communications Planning  49 Abbeygate Street
Bury St Edmunds   Suffolk  United Kingdom  IP33 1LB
Phone: +44 1284 750658
Fax: +44 1284 750620
Email: ahinchley@communicationsplanning.ltd.uk Web: www.communicationsplanning.ltd.uk/
 
Biographical notice:
Markwell, David C
 Reading 
The Clinical Information Consultancy
 United Kingdom  
 
Andrew Hinchley runs his own consultancy company, specialising in communications, particularly in healthcare. He has played a very active role in the developments of methods for specification of clinical messages. The message design methodology developed in the European healthcare standards group CEN TC251 offers for the first time the ability to provide detailed conformance and quality checks on clinical message implementation. He has been actively reviewing XML for this and other healthcare applications over the last 18 months
 David C   Markwell
  Principal Consultant
  The Clinical Information Consultancy  93 Wantage Road
Reading   Berkshire  United Kingdom  RG30 2SN
Phone: +44 118 9584954
Fax: +44 118 9504464
Email: david@clinical-info.co.uk Web: www.clinical-info.co.uk
 
Biographical notice:
 
David Markwell is medically qualified and has been involved in the development of healthcare record systems since their introduction for primary care in the UK. After working for a supplier of medical record systems, he is now been running his own consultancy for the last ten years. He has lead a number of European initiatives on healthcare standards. The healthcare record message pre-standard which is the subject of this talk is being developed by a team lead by David Markwell.
 

Messages to transfer the electronic patient record
 
The XML application described in this paper arises from the need to transfer comprehensive structured patient records as a patient moves from one community doctor (GP) to another. This is a current problem in the UK, since although the use of structured EHCRs well established, there is no universal way to transfer this information between systems using proprietary databases structures in their implementation.

Provide EHCR Message


>

 
 
The process of developing the EHCR messages over the last year is part of a wider initiative to define standards for electronic health care records. in the European standards group for health: CEN TC251.
 
Messages developed to transfer the EHCR can be used in a number of contexts, other than the one on which the UK is currently focussing. Another example is exchanging information to support shared care between several physicians. For instance the patient's regular physician and a specialist physician at a secondary care establishment.
 
The diagram below illustrates a shared care model, where the Provide EHCR is one of several messages needed to support the flows shown.

Shared Care Model


>

 
 
The project in which XML implementation is being evaluated (XMLEPR) is a message validation activity, jointly sponsored by the European Commission (as part of the ISIS XML/EDI project), the UK National Health Service and the UK Royal College of General Practitioners. The first phase of this will be completed in April 1999 but the XML/EDI project will run until the end of 1999.
 

Decision to Use XML
 
This project is the first attempt in Europe to use XML for the rich data structure needed to support an EHCR. The success so far, confirms that many other healthcare messaging applications should also be able to be supported in a similar way.
 
There are some specific conclusions so far:
 
  •  The XML1.0 specification has been found adequate so far to support all the constructs needed so far;
  •  The XML1.0 specification has been found adequate so far to support all the constructs needed so far;
  •  Although XSL has a significant role to play where integrated date entry/transfer/display are needed, for healthcare process-process applications, such as record transfer, there is no requirement to specify display and therefore XSL and CSSL are not required;
  •  Standardised use of XSL will also be relevant when wanting to implement specific scenarios with interactions between sender-dictated display and receiver-dictated display.. The multi-media XSL-related specification SMIL has been successfully evaluated for this type of application.
 
Proposals that a "cut-down" XML should be used for EDI messaging are however believed to be mis-guided, since experience has shown that access to all the standard tools has been invaluable and creating a separate different specifications for messaging would be unfortunate and against the spirit of the W3C recommendations.
 

Work on XML for messaging in XML/EDI and TC251
 
In Europe, two of the major thrusts on investigating use of XML for messaging have been the CEN ISSS Electronic Commerce workshop and the CEN healthcare standards group already mentioned.
 
CEN TC251 started looking at these issues at the end of 1997 and in mid-1998 a technical report on the use of XML was published www.centc251.org/ . This study resulted in the setting up of a task force under Professor Joachim Dudeck. In autumn of 1998, a first draft DTD was produced, corresponding to the EPR transfer message standard www.communicationsplanning.ltd.uk/ahinchley/
 
The XML/EDI work in Europe has been co-ordinated by the CEN ISSS Electronic Commerce workshop http://www.cenorm.be/isss/workshop/ec/xmledi/isss-xml.html
 

XML/EDI and XMLEPR projects
 
The European XML/EDI project established at the beginning of 1999 is sponsoring message development for a number of sectors and the collective result of this experience is part of the overall XML/EDI message development methodology. The objective of the European project is to feed back to the standards arena from the practical work carried out in 1999. This work is supported by the European Commission under the DGIII ISIS Programme. XMLEPR is part of the European XML/EDI project.
 
Work in these projects is based on substantial experience in design and implementation of structured messages. This has shown that the data structures need to be fully defined and shared between the co-operating systems if the information is to be as fully available in the receiving system as it was in the sending system.
 
The logical conclusion from this in XML terms is to use valid and well formed DTDs, requiring that XML messages correspond to the DTD in full, i.e. no undefined tags. Means to extend these standard DTDs to meet local requirements remains of course a requirement
 

Automated mapping from UML model/object database
 
One of the great steps forward resulting from this work is the ability to automatically generate XML DTDs from the UML models and object databases used to describe the data structure to be transferred - a generalised patient record structure. The tools used are specific for the project, but the conclusions are general. The XML mapping rules defined below are a set which can potentially, support any of the healthcare messages that have been defined by TC251 over the last 5 years.
 

Refinement of specific mapping rules
 
A set of about 20 mapping rules have been found adequate to automatically produce an XML DTD corresponding to the message represented as a UML model with supporting objects/attributes.
 
The following 6 rules listed below show the general approach of these rules. A further 12 rules are needed to pick up particular cases arising out of the models used.
 
  •  Use of parameter elements in all cases, other than where rules make exceptions;
  •  Attributes for a small number of specific identified cases, such as enumerated lists;
  •  Use "optional", "mandatory", "0 or many", "1 or many" as exact mappings from model to XML;
  •  "One or more of" are mapped as (A B? C?)|(B C?)|C);
  •  "Choice" is mapped as (A|B|C);
  •  "Empty" hierarchies in the model which can be collapsed and not represented.
 

Clinical validation of the XML-based EPR transfer message
 
Experience, particularly in the UK, has shown that clinical validation is a challenging, but essential part of the mass introduction of new electronic methods into every day patient care. Some of the major benefits of using XML are expected to come from achieving a better quality of validation.
 
The challenges come from devising a method of validation that:-
 
  •  Provides evidence that clinical safety is being safeguarded
  •  Is adequately transparent to a wider group of clinicians than just a few technical experts
  •  Once validation is complete, can allow multiple implementations by many suppliers with the minimum need for further detailed clinical evaluation of each implementation
 
The process of clinical validation involves the production of XML messages (each being a patient record extracts) by exporting several patient records from a variety of clinical information systems. The information is exported in the form of an XML document that complies to the DTD for the Provide EHCR message. These messages are then viewed through one or more of a selection of the available XML browsers or viewers,or a specially developed viewer. The available viewers used have included freely distributed products such as Microsoft's XML Notepad and Internet Explo
 
One of the main software deliverables of the project has been a special XML viewer developed. The viewer is designed to ensure that those parts of the message of most interest to clinicians can be displayed in a way which directly supports the evaluation process. This viewing activity is purely a function of validation. Once implemented, these process-process messages do not require to be displayed.

XML Viewer


>

 
 
Clinician compare views of the record within the original application with the content and structure of the message. Comments on discrepancies or inadequacy can then be added (using the project specific viewer) and these are fed back for analysis.
 
Particular features of the specially developed XML viewer are:-
 
  •  IE5/XML Notepad-style display of the XML hierarchy ;
  •  No modification or change to the information contained in the record ;
  •  Display of the main clinical components of the XML patient record extract ;
  •  Look-up of clinical codes (by holding a code directory look-up list in the viewer) ;
  •  Search string capability across the message (which may be extensive in length).
 
At the time of writing this paper, solid results are already becoming available from the project. Of the 4 suppliers of GP computer systems involved, two have been able to extract fairly comprehensive structured records from their own proprietary record systems. The companies involved, EMIS and In-Practice Systems have achieved excellent results within the tight time constraints that the XMLEPR project has set itself.
 

Issues-looking to the future
 
The key next stage once the work described is complete will be to evaluate the receipt of EPR transfer messages and assimilation of the information to the patient record at the receiving system. These challenges are related to the different database structures used indifferent systems and the different way in which clinical aspects of the patient record have been recorded. It is critical that the EPR message structure and its XML representation are powerful enough to achieve the desired results.
 
Once at that point, there are then a number of further XML issues that will need to have been solved in order to move to real implementations in day-to-day healthcare.
 

Validation
 
Sending structured information from one legal entity to another is problematic if the receiver is to take full responsibility for the semantics of what has been sent, without full scrutiny by an expert of every last tagged item.
 
Implementing satisfactory validation has however been a huge problem in messaging over the last decade. This is for a number of reasons:-
 
  •  Finding a way of expressing the constraints on use which may apply
  •  Ensuring that the sender fully conforms to these constraints before sending a message
  •  Dealing with validation failures found by a receiver
 
A first requirement on any solution is to be able to fully automate whatever checking mechanisms are to be put in place.
 
In a XML context, there are a number of ways in which we can seek to meet these requirements:-
 
  •  Capture all validation at the XML level and ensure that that the sender is going through the same validation mechanisms as the receiver;
  •  Investigate XML -related facilities such as architectural forms to support validation;
  •  Investigate use of XSL/CSSL (however this may be a major diversion for contexts where presentation is not a relevant requirement )
  •  Investigate use of RDF
 
It will be part of the European XML/EDI project to investigate these alternatives once the requirement is better understood.
 

Conclusion
 
The work achieved so far is promising in providing high quality XML-based solutions at a much lower effort than with previous messaging methods.
 
It will be important to inject into the standards activity, enough of the results for this work to accelerate take-up, but not over limiting the way that solutions are implemented.This is the mandate of the European XML/EDI project.
 
On-going work on many fronts in XML development will be promising if additional facilities can be harnessed in the way that XML 1.0 has been used as described in this paper, but negative for messaging applications, if it leads to too much diversity in facilities used and hence inoperable systems.
 
Acknowledgments
 
The authors wish to express their thanks to the European Commission DGIII Programme, the UK National Health Service and the UK Royal College of General Practitioners
 
Bibliography
European Committee for Standardization, CR 12587:1996, CEN Report: Medical Informatics - Methodology for the development of healthcare messages.
European Committee for Standardization, Medical Informatics PT26- Electronic healthcare record architecture.Part 1 - Extended Architecture
European Committee for Standardization, PT29 Medical Informatics - Electronic healthcare record architecture Part 4- Messages for the exchange of information
DrawML and SVG   Table of contents   Indexes   Information and Content Exchange