Medical Markup Language (MML) for XML-based. Hospital Information Interchange. Kenji Araki,1,9 Katsuhiro Ohashi,2 Shunji Yamazaki,3 Yasuyuki Hirose,3.
Journal of Medical Systems, Vol. 24, No. 3, 2000
Medical Markup Language (MML) for XML-based Hospital Information Interchange Kenji Araki,1,9 Katsuhiro Ohashi,2 Shunji Yamazaki,3 Yasuyuki Hirose,3 Yoshinori Yamashita,4 Ryuichi Yamamoto,5 Kazushi Minagawa,6 Norihiro Sakamoto,7 and Hiroyuki Yoshihara8
Medical Markup Language (MML) has been developed over the last 6 years in order to create a set of standards by which medical data, within Japan and hopefully worldwide, can be stored, accessed and exchanged in any number of physical locates. The MML version 2.21 is characterized by XML as meta-language, module structure for each document and enhancement of linking function among documents. Data exchange specification has been also added for query and reply. MML instances are composed of MML header and MML body. The MML header includes information for data transmission, while MML body includes several module items. One module item contains two elements: document information and module content. Nine MML module contents are defined at the present time: patient information, health insurance information, diagnosis information, lifestyle information, basic clinic information, particular information at the time of first visit, progress course information, surgery record information and clinical summary information. KEY WORDS: XML; XML namespaces; EDI; medical record.
1
Medical Informatics, Miyazaki Medical College Hospital 5200 Kihara, Kiyotake, Miyazaki 889-1692, Japan. 2 Ohashi OB/GY Clinic, 4–4–2 Ebara, Shinagawa, Tokyo 142, Japan. 3 Medical Informatics, University Hospital, University of the Ryukyus, 207 Uehara, Nishihara-cho, Okinawa 903-0215, Japan. 4 Yoshinori Yamashita M.D., Medical Informatics, Fukui Medical University Hospital, 23 Shimoaizuki, Matsuoka, Yoshida, Fukui 910-1193, Japan. 5 Medical Informatics, Osaka Medical College, 2-7 Daigaku-cho, Takatsuki, Osaka 569-8181, Japan. 6 Digital Globe, Inc., Silk-Bld. 817, 1 Yamashita, Naka-ku, Yokohama 231-0023, Japan. 7 Medical Informatics, Kyushu University Hospital, 3-1-1 Maidashi, Higashi-ku, Fukuoka 812-8582, Japan. 8 Medical Information Technology, Kumamoto University Hospital, 2-2-1, Honjo, Kumamoto 8600811, Japan. 9 To whom correspondence should be addressed. 195 0148-5598/00/0600-0195$18.00/0 2000 Plenum Publishing Corporation
196
Araki et al.
INTRODUCTION Since 1994, the Japan Association for Medical Informatics ‘‘Electronic Health Record Research Group’’ has been studying the method to electronically exchange medical data between different institutions. In 1995, an idea that data are exchanged with attributes was created and further developed into the Standard Generalized Markup Language (SGML; ISO 8879:1986). This standard was named the Medical Markup Language (MML) and was brought out to the public as the first version of the MML for electronic health record data exchange specification. As implementation of MML has developed, the features specifically designed for various medical fields have been required. It is impossible for this group to cover the entire medical fields. Considering influence on the entire structure arising from additions/changes of the partial structure that may occur frequently, it is not efficient to manage the version control. In Version 2.21, each document was put into a module using the XML Namespace,1 which was recommended at W3C in March, 1999, for availability of a combination of modules as required. This has allowed description particular to each medical field efficiently. In addition, when various data output methods are prepared for each application vendor, data cannot be obtained unless the data request is prepared according to the format specified by the vendor. Assuming that information is exchanged among multiple hospitals or medical information providers, it is necessary to specify the method of data request, response and deletion based on MML. Therefore, the new version has implemented the specification of data exchange. This specification and relevant data are disclosed and managed at the Seagaia Meeting web site.2 The MML Version 2.21 Standard3 has a volume of 146 pages including the definition and explanation of the structure, sample instances, DTDs and table of lists. Since this paper only outlines the MML project, we refer you to profound data on the Seagaia Meeting web site.2 OUTLINE OF VERSION 2.21 The features of MML Version 2.21 are as follows: use of XML as a metalanguage, module format of documents, clear definition of module granularity, improvement of link function between documents, etc. The specification consists of two parts: the Data Format Specification and the Data Exchange Specification. XML The new version has used XML Version 1.04 as a meta-data description language for exchange, which was recommended at W3C (world wide web consortium). The following rules were also provided. 1. Use XML Namespace for segmentation and modularization of document structures. Information particular to each medical application must be described with XML Namespace.
Medical Markup
197
2. Use XHTML as the Presentation Data (format including the data for presentation). 3. Use the specification of ISO 86015 for the format of date, time, dateTime and timePeriod. Modularization of Documents The MML basic structure is used as the mainstay of the MML instance. Documents in the form of modules are incorporated into the basic structure. Currently, the following nine modules are defined: Patient information Health insurance information Diagnosis information Life style information Basic medical information Particular information at the time of first visit Progress course information Surgery information Clinical summary information Definition of Module Granularity Definition of a module applicable range, i.e., document granularity, allows a link between documents. In the MML, one diagnosis information module is defined as a representation of one disease. In addition, the applicable range of one particular information at the time of first visit refers to information at one initial visit, one progress course information module refers to one description at one time by one person, one surgery information module refers to information from entry to exit, and one clinical summary information module refers to one hospitalization record for a summary at discharge from the hospital. Improvement of Link Function Between Documents Each module has a unique document ID. With this document ID, inheritance from the parent document to multiple sub-documents can be indicated. Using this function, correction of document, relation between an order and the result, relation between a question and the result, indication how the diagnosis was changed, applicable health insurance for the diagnosis, and preparation of summary with combination of documents can be achieved. MML Basic Structure The MML mainly consists of two blocks (Fig. 1). Information groups with high frequency of reuse are defined as the common format.
198
Araki et al.
Fig. 1. Elements of MML basic structure.
MML Header Block The header has the information to transmit the entire MML instance, not the individual module. These details are transmission time, ID of sender, its name, facility name, ID of patient, applicable period of entire instance, encryption information, etc. The name of the patient and its gender are described in the patient information module and they are not shown on the header. ‘‘toc’’ (table of contents) has the URI list of information contained in the body block. The actual system can reject all data or accept part of the data if the URI information block not applicable to the URI information lists appears in the body. Check of ‘‘toc’’ in the header through the system allows you to know what data is contained without seeing the body. MML Body Block The body receives multiple document modules with repetition of MmlModuleItem. However, one ModuleItem has only one module. Therefore, docInfo, i.e., document information is added to each module. The document information shows
Medical Markup
199
the access right information, document title and type, document ID, inheritance from parent ID if required, confirmation date of document, creator information, etc.
MML Common Format Information groups with high frequency of reuse are summarized as the MML common format. The following common format is available. Address format Telephone number format Id format External reference format Name format Facility format Department format Personalized information format Creator format
MML Module Patient Information Module The patient information module shows the basic information of a patient such as patient ID, name, birth date, address, etc. (Fig. 2).
Fig. 2. Elements of MML module (Patient information).
200
Araki et al.
Health Insurance Information Module The health insurance information module shows the applicable health insurance information. Currently, the health insurance module is available only in Japan. If the MML is used outside Japan, the insurance information must be newly developed for each country (Fig. 3)
Diagnosis Information Module The diagnosis information module shows one diagnosis name and supplementary information. Supplementary information includes the types of diagnosis such as confirmed diagnosis and pathological diagnosis, the diagnosis date and the prognosis (Fig. 4).
Life Style Information Module The life style information module shows a patient’s occupation, use of cigarettes, alcohol, etc. (Fig. 5).
Basic Clinical Information Module The basic clinical information module shows allergy information, blood type and infection information such as hepatitis B (Fig. 6).
Particular Information at the Time of First Visit Module The particular information at the time of first visit module shows the family history, birth information, past history, chief complaint and history of present illness (Fig. 7).
Progress Course Information Module The progress course information module is equivalent to the progress note. It shows daily medical record, test order and test result. The test order or the test result can be prepared in an HL7 file with the external reference method. In this module, either a free description without structure or a structured description divided into SOAP can be selected (Fig. 8).
Surgery Information Module The surgery information module is equivalent to the operative note. It shows the surgery date and time, department, operative diagnosis after surgery, operation method, anesthetic method, staff, operative free note, etc. (Fig. 9).
Fig. 3.
Elements of MML module (Health insurance information).
Fig. 4.
Elements of MML module (Diagnosis information).
Medical Markup
203
Fig. 5. Elements of MML module (Life style information).
Clinical Summary Information Module The clinical summary information module shows summarized information for the specified period. Visiting history (hospitalization or outpatient) can be described. Usually, it is used as a discharge summary from the hospital (Fig. 10). Data Exchange Specification In Part 2 of the MML Standard, the data exchange method is defined. The following commands are defined. mmlAppend mmlDelete mmlQuery mmlResult mmlItemResult
(request for addition of data) (request for deletion of data) (request of data) (result for query) (result for query in module item)
The query is given in a questionnaire. The required module is provided with empty tags. Such tags should be filled in for response. The applicable information period can also be specified.
DISCUSSION There are some standards for medical information other than the MML. In European countries, the most popular standard is the Electronic Data Interchange (EDI)6–8 according to the UN/EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport standard) which is the message exchange standard for trading established by the United Nations to allow exchange of structured data. Furthermore, the Netherlands has developed a protocol called MEDEUR for medical purpose using the EDIFACT standard. The medical association in the Netherlands is managing this system.9 In the United States, the Health Level Seven (HL7) is generally used to exchange medical information,10 and the HL7 SGML/XML Special Interest Group is developing the HL7 Document Patient Record Architecture.11,12 The MML is mainly designed to describe comprehensive medical information. In contrast, the HL7 is designed to exchange the database for each specific purpose (use case). The MML does not specify a combination of modules for a specific
Fig. 6.
Elements of MML module (Basic medical information).
Fig. 7.
Elements of MML module (Particular information at the time of first visit).
Fig. 8.
Elements of MML module (Progress course information).
Fig. 9.
Elements of MML module (Surgery information).
Fig. 10.
Elements of MML module (Clinical summary information).
210
Araki et al.
purpose, but it is suitable for a case of transmission of ‘‘comprehensive’’ medical information when a patient is referred. Since many trials other than MML and HL7 are reported for structuring medical records with XML,13,14 increasing need to transform one markup to another markup develops. XSL (Extensible Stylesheet Language) provides a rule to transform markups.15 It is also important to cooperate among developers and organizations of various standards. ASTM E31.25 subcommittee, ‘‘XML DTDs for Health Care’’ is formed to enhance existing levels of interoperability among the various XML/ SGML standardization efforts, products and systems in health care.16 It is difficult to perform correct exchange of the particular information at the time of first visit and the progress course information out of nine MML modules between databases because this information consists of narrative free notes. Considering visual recognition, the MML also recommends use of XHTML to add the style information. Although the MML is developed in Japan, it is not limited to use in Japan only. All specifications are in accordance with the internet standard expecting implementation on a worldwide basis. BizTalk is an international organization that supports various standards of XML for a particular field. The MML has used CamelCase for names of elements and attributes. It is designed according to the BizTalk framework guidelines.17 To allow implementation of the standard on a worldwide basis, the essential point is extensibility for each country. In the MML, additional development of a module allows extension of function for each country. To be compatible with various kinds of medical information, extension of the current MML will be required in the future. There are several initiatives for extension. If only addition of style information is required just for understanding of a person, XHTML or XSL may be used. If the content is narrative, only addition of the style information may be sufficient. To build the detailed structures for each element, extension using the XML Namespace is also available. Another method is revision of the MML specification and the MML module is newly defined. It is the best method to ensure high popularity. In this paper, a rough outline of the MML Version 2.21 is explained. The MML is being implemented at multiple facilities. In the future, we would like to verify effectiveness of the MML as the exchange standard while checking problems from implementation.
ACKNOWLEDGMENTS The authors of this paper as core members together with working group members have developed the MML Version 2.21. Mr. Yoshiyuki Kitahara (Infoteria Co. Ltd., Japan) has played a central role in development of the MML with XML format and the data exchange specification. We sincerely thank all members involved in this development.
Medical Markup
211
REFERENCES 1. Namespaces in XML World Wide Web Consortium 14-January-1999. http://www.w3.org/TR/1999/ REC-xml-names-19990114/ 2. Seagaia Meeting Home Page http://www.seagaia.org/sgmeeting/sg_e.html 3. MML working group. MML specification Version 2.21. Japanese Association for Medical Informatics Electronic Health Record Research Group, 1999. 4. Extensible Markup Language (XML) 1.0 W3C Recommendation 10-February-1998. http:// www.w3.org/TR/1998/REC-xml-19980210 5. Date elements and interchange formats—Information interchange—Representation of dates and times. http://www.iso.ch/markete/8601.pdf 6. Kinkhorst O.M., Lalleman AW, Hasman A. From medical record to patient record through electronic data interchange (EDI). Int. J. Biomed. Comput. 42(1-2):151–155, 1996. 7. Love, B.J., Developing EDI messages and supporting data models: a ‘‘bottom up’’ approach based on ‘‘single business purpose’’ messages meets user needs. Medinfo.8 Pt 1:212–215, 1995. 8. Hasman, A., Ament, A., Arnou, P.C., and Van Kesteren, A.C., Inter-institutional information exchange in healthcare. Int. J. Biomed. Comput. 31(1):5–16, 1992. 9. Branger, P., van’t Hooft, A., and van der Wouden, H.C., Coordinating shared care using electronic data interchange. Medinfo. 8 Pt 2:1669, 1995 10. Stitt, F.W., A standards-based clinical information system for HIV/AIDS. Medinfo.8 Pt 1:402, 1995. 11. Dolin, R.H., Alschuler, L., Behlen, F., Biron, P.V., Boyer, S., Essin, D., Harding, L., Lincoln, T., Mattison, J.E., Rishel, W., Sokolowski, R., Spinosa, J., and Williams, J.P., HL7 document patient record architecture: An XML document architecture based on a shared information model. Proc. AMIA Symp. 52–6, 1999. 12. Dolin, R.H., Rishel, W., Biron, P.V., Spinosa, J., Mattison, J.E., SGML and XML as interchange formats for HL7 messages. Proc. AMIA Symp. 720–4, 1998. 13. Kahn, C.E., Jr., and de la Cruz, N.B., Extensible markup language (XML) in health care: integration of structured reporting and decision support. Proc. AMIA Symp. 725–9, 1998 14. Chueh, H.C., Raila, W.F., Berkowicz, D.A., Barnett, G.O., An XML portable chart format. Proc. AMIA Symp. 730–4, 1998. 15. Seol, Y.H., Johnson, S.B., and Starren, J., Use of the Extensible Stylesheet Language (XSL) for medical data transformation. Proc. AMIA Symp. 142–6, 1999. 16. Sokolowski, R., and Dudeck, J., XML and its impact on content and structure in electronic health care documents. Proc. AMIA Symp. 147–51, 1999. 17. BizTalk framework guidelines: http://biztalk.org/
