Prof. Yasuyuki Hirose
Department of Medical Informatics, The University of the Ryukyus, JAPAN

The Current Status of CPR in Japan

This document was described as one of the fuculty on the workshop (International Progress in CPR) in Medinfo'98
for the reply to the questionnaire on 6/18/98 from coodinators.

uploaded 1998.7.24

CONTENTS
Q 1.  Describe the status of the CPR on your continent.
	Overview
		spread of hospital information system
		short history of hospital information system
		staff and atmosphere
	In the Inpatient setting
	In the Outpatient setting
	Definition of CPR
		goals and principle
			end-users, esp. doctors
			system providers
			government
		functional definitions
		what differences are essential : CPR vs. patient-centered order-entry ?
	Social environments
		law
		medical care framework
	Handling of the Japanese language
		input method
		processing

Q 2.  Describe the vision, strategy and goals for the CPR on your continent.
	Overview
	What are you going to do next year ?
	What do you plan to do in the next 3 to 5 years?

Q 3.  Describe how the CPR on your continent is addressing the following issues.
	Structure/Architecture
		from MF-centered to C/S
		trial for object oriented
	Modularity  (Best of breed or one-vendor approach?)
	Security
		inside hospital/clinic
			identification and certification
			log and audit
			policy and rules
		for the outside or public network
			fire-wall and network topology
			encryption and certification
	Patient Identifier
	Terminology and Standard Nomenclature
		standards which are often used as a base
		why hasnt the standardization of terms/codes been achieved in Japan ?

Q 4.  Describe the lessons learned while developing and implementing the CPR
	Success factors
	Reasons for failures

Q 5.  Identify installations that exemplify the CPR on your continent.

Q 1. Describe the status of the CPR on your continent.

In the inpatient setting
In the outpatient setting

1. Overview

1.1. spread of hospital information system

Although the spread of hospital information system (HIS) in Japan is 54.1% according to official data. This number does NOT represent the actual diffusion of CPR systems, because the number includes, among many things, order-entry systems and the systems which have only a financial module. This fact shows disparity between the status or extent of computerization of each hospital or clinic.

1.2 short history of hospital information system

Prior to a few years ago, almost all HIS in Japan were a combination of order-entry systems (mainly pharmacy modules and lab modules), clinical department systems, and financial systems. Although a few hospitals or clinics have attempted to develop CPR, examples of cases that have developed the system include (i) those accomplished within private management in clinics, (ii) governmental experiment in few department of small scale hospitals or sanitariums, and (iii) those developed through hospital policy.

Under these circumstances, most of the HIS stay in order-entry systems. Therefore, the implementation of CPR in many hospitals and clinics has just begun in general. Consequently, POMR & SOAP description modules of CPR are currently being designed, developed, and/or examined. Then very few of them have been implemented to the fullest extent.

1.3. staff and atmosphere

In Japan, the PA (physicians assistant) does not exist, and the duties or job range of nurses are limited. In addition, most hospitals do not have clerks in clinical offices or wards, so needless to say, doctors are easily overloaded. What more, Japan is unique in that the data/order entry is directly performed by doctors themselves at the point-of-care.

On the other hand, because doctors are rather self-reliant and the control power of the hospital director is rather weak, doctors tend to conduct themselves and their time as they like. This means that they may often neglect their duties of writing down information on medical charts, whether it be electronically or manually.

2. In the Inpatient setting

Functions are listed as follows;

However, hospitals which have almost all of the above functions are few in number. The main reasons are cost, slow development speed of vendors, and data/order entry.

In addition, it is rare that all of the functions are used routinely in every one of the clinical departments or wards, especially drip injection order and diagnoses/problems/findings entries. The reason for the former is the frequency of the changes in orders, and the reason for the latter is that it can be tiresome for a doctor to enter data/information. In other words, they may tend to avoid data entry, or the computer system in general.

3. In the Outpatient setting

This setting is almost the same as the inpatient one. In fact, the same modules or systems are used in the outpatient offices. HISs distinguish between outpatients and inpatients by one of status flags of the patients information registries, and this flag is controlled by the admission/discharge module.

In the past, the time for the patient-doctor encounter was so short that patients often complained of a three hour wait for a three minute encounter. And while this aspect has been improved (though not perfected), the principle of direct data/order entry by the doctors themselves at their point-of-care allows doctors very little time to perform data/order entry. Thus they are inclined to commit to only what data/order items directly produce money, and to neglect what items may not be money makers although they are very important in clinical decision making, for example, register prescription but do not enter significant signs/symptoms. This situation is one of the preventing factors in the spread of CPR.

4. Definition of CPR

By the way, What is CPR ? and What are the differences between CPR and order-entry system ? Without these answers, we cannot properly discuss the aspect of CPR.

I apologize if I might have misunderstood, but I assume that the coordinators have concealed this problem intentionally, in order to avoid our facultys confusion before the discussion in Korea. In fact, in Japan there is no unified or authorized concrete definition, and there are also some differences in the goal or principle of CPR between end-users, system providers, and the government.

However, I can not ignore this because without the definition of CPR, Im afraid my reply to the questionnaire may to fall into meaningless comment. So I will try to illustrate the broadest image of CPR in Japan.

4.1. goals and principle

end-users, esp. doctors

About five years ago, many desired and anticipated comprehensiveness in general. Systems were expected to record entire events in clinical course, and provide all of the functions to record those events. Systems should also execute financial issue and support hospital management. This concept was brought out by the desire to widespread the order-entry system, and this desire peaked about eight years ago. But the desire was only focused on functions or human interface, and the required efforts, such as database design, were rarely performed. In the past (and even in some cases today), most of the HIS database were only transaction files rather than true database.

On the other hand, a few people desired integration rather than comprehensiveness. They have argued that systems should integrate available data/information of a patient within the system. This is quite different from the comprehensive aspect at three points: (i) database or data warehouse schema is designed to focus on patient or patients medical history, (ii) the recording of available data/information is practical but not comprehensive, and (iii) those data/information is referred and showed on a electronic chart, not as order-entry centered, but as a patient-centered image which reflects the data warehouse schema.

By the end of this century, the integration aspect is going to become the main current among end-users because its possibility of improving the quality of clinical procedures.

system providers

System providers say that (i) they aim to develop the electronically processing system for the entire or partial information of doctor's charts, nursing records, lab data, medical images, etc., and (ii) the goals provide clinical support, distribution and delivery of clinical information without time lag, the promotion of the patients right to select or control, the audit of the appropriateness of care and medical service (not manually but by system automation), the promotion of clinical study, the contribution of hospital management and strategy, and the promotion of a paperless hospital.

While these aims and goals are acceptable, they also say that (iii) CPR is the system which has been developed with these aims and goals. I found this third point to be very peculiar.

government

Authorities are urged to decrease the cost of medical care and welfare without lowering the quality of care. For this purpose they seems to have some measures, and one of them is the diffusion of CPR widely. Because CPR is essential for the enforcement of DRG/PPS (Diagnosis Related Groups / Prospective Payment System) and for maintaining the appropriateness of medical care/services through the system audit.

What more, there seems to be some plan in which authorities may attempt to re-structure hospitals, especially governmental or prefecture hospitals using the process described above.

4.2. functional definitions

Although goals and principles are important in the constructing of CPR, functional definition is also necessary. One reason is to evaluate whether the actually implemented system is CPR or not, and another is to understand each other from different continents for the sake of fruitful discussion. Therefore Ive attempted to describe the characteristics of a CPR, or a patient-centered information system;

  1. CPR system should provide the ability to share clinical information and communicate between staff in different places and times. In addition data/information should be shared between those modules/functions described below. This sharing between staff and betwenn modules/functions leads to the idea that the system has to run most clinical departments in a hospital (in principle).
  2. CPR system should provide a Basic Module which contains functions for maintaining the following: identifier, demographic data, familial data, registration of visits, financial data, security mechanisms, and so on.
  3. CPR system should provide a Medical Module. This contains the following functions;
    • to register and maintain the diagnoses or problems (problem list) and their attributes
    • to register and maintain complaints, signs, and symptoms (SOAP)
    • to integrate data/information registered on SOAP to the diagnoses or problems
    • to refer the history and results of medical actions by booting other Modules
  4. CPR system should provide Order-Entry Modules.
  5. CPR system should provide Referring Modules. This contains the functions of;
    • Lab test data
    • Medical images
  6. CPR system should provide a Nursing Module. This contains functions to register and refer the history of nursing actions.
  7. CPR system should provide the human interface environment which integrated those module as patient-centered view.
  8. CPR system should provide the ability to link clinical data/information to each other semantically. This function has to be strictly distinguished from the relation of relational database schema or the key of record layout in COBOL.
  9. CPR system should provide various kinds of support systems.

Im afraid it is too difficult for an actual system to be qualified or evaluated as a true CPR system, at least in present day. In fact, I should say there is no CPR system in Japan if it has to have all of the functions/conditions described above and all of them are only so-called CPR systems. But I think it is feasible that we allow the system which is planned to be implemented stepwisely to a CPR system, so we can regard the so-called CPR system which has most of the functions/conditions above as CPR.

Therefore Ive treated so-called CPR system as CPR in the previous sections entitled In the inpatient setting and In the outpatient setting.

4.3. what differences are essential : CPR vs. patient-centered order-entry ?

In the transition from a order-entry system to a CPR system, the border between the two sides tends to become obscure because of two major reasons. One reason is that human interfaces look patient-centered, and another is that the system contains the medical history of patients. Therefore, there exists so many so-called CPR systems in Japan (and worldwide?) that the distinction becomes unclear.

If any, what differences are essential between CPR and order-entry system in this situation ?

We believe that the difference is that in CPR, the implementation of Electronical POMR and SOAP (related to # 3) and the linking ability of clinical data/information to each other semantically (related to # 7 and # 8) exists. Each order-entry modules is able to implement sectionally due to their functions, but a CPR essentially requires the integration of entire modules or integration of entire clinical data/information inside the system.

In this sense, whether CUI or GUI is used would not be an essential criterion (although the CUI system can not support the referring function of medical images).

5. Social environments

5.1. law

The law regulating doctors behavior states that doctors should write down the contents of medical care. In other words, the law prohibits CPR and forces to use/keep paper medical chart, because the doctor cannot write down rather the doctor registers in the CPR system.

However, authorities recently seem to be silent approving (looking away from) CPR, and this may be a step in the spread of the CPR system. In addition, authorities planned two years ago for the revision of the law after 1998.

5.2. medical care framework

The law regulating health & welfare states that all citizens should enroll in public medical insurance. Citizens pay the premium according their income. When they receive medical treatment, he/she must pay only about 20% to the hospital/clinic, and the rest is paid by insurer and by the government. This insurance system has been appreciated as one of the property re-distribution system and as providing policy for a long time. However the system is coming to a yield now a days due to the high cost of medical care.

6 Handling of the Japanese language

6.1. Input Method

The Japanese language has traditional and proud ideographical letters, Kanjis (so-called Chinese characters) and phonographical letters, Kanas. There are more than twenty or thirty thousand Kanjis, and just those designated for daily use reach a few thousand. On the other hand, the Japanese language has many homophonic words. These two features make the entry of the Japanese language unique and difficult:

  1. From the system's view, the Japanese letters entry module traps keyboard inputs via OS to a targeted application, then converts alphabets to Kanjis, and finally hands them over to the target.
  2. From the end-user's view, she/he types alphabet letters which phonetically represent Japanese words, then the module converts these letters to Kanji but it often fails because of so many homophonic words. As a result, an end-user has to let the module re-convert again until it converts correctly.

After these LONG steps, the doctor can enter only ONE Japanese word. This is obviously unfavorable and disadvantageous when entering clinical data/information on CPR, because (i) it takes too much time; and (ii) there is too much interruption in the thinking process.

The latter is more critical because the data/order entry is performed directly by doctors themselves at the point-of-care, in Japan.

6.2 processing

A thousand or more letters each have typographic figure. This means that even a minimal set of Kanjis and Kanas cannot be represented by a one-byte code system. Therefore, the two-byte code system with a smart mechanism which follows International Standard has been used widely for a long time. This is disadvantageous for platforms and modules to process Japanese characters/letters, due to program complexity. Consequently, program size and necessary memory size tends to be large, and execution is rather slow and heavy.


Q 2. Describe the vision, strategy and goals for the CPR on your continent.

What are you going to do next year?
What do you plan to do in the next 3 to 5 years?

1. Overview

We are currently in the transition between order-entry systems and CPR or patient-centered information systems. I guess that it will take about six years to accomplish the development of CPR among major hospitals. During this transition, the smooth and safe shift is the most important factor for each hospital.

2. What are you going to do next year ?

JAMI (Japan Association of Medical Informatics), JAHIS (Japanese Association of Healthier Information Systems Industry), JIRA (Japan Industries Association of Radiological Systems) and MEDIS-DC (Medical Information System Development Center) are absorbed in their work. I project that we will be able to get an outcome of the following items from them in the next year:

Most of them have been bred in working groups of JAMI or JAHIS.

3. What do you plan to do in the next 3 to 5 years?

This actually depends on both our research budget and the economic strength of Japan ! Therefore it is rather difficult for me to predict this. I can venture to say, however, that our plans for the future include;


Q 3. Describe how the CPR on your continent is addressing the following issues.

Structure / Architecture
Modularity (Best of breed or one-vendor approach?)
Security
Patient Identifier
Terminology and Standard Nomenclature

I am able to explain the current state of CPR in Japan so far as I know, and Im afraid that I can not refer those in other Asian countries.

1. Structure/Architecture

Almost all of the HIS in Japan have been constructed based on main frame (MF) and COBOL. When going to use CPR or the so-called CPR, a kind of Client/Server model becomes necessary. This reflects the transition period today.

1.1. from MF-centered to C/S

However, in my opinion, most of these C/S style seems to be superficial or primitive, or a legacy of MF/COBOL now. Most of these do not have an order communication module or a inter-system communication module or middle ware in broad sense yet. Whole transactions still gather and crowd on MF, and the jobs (i.e. programs and their related files; legacy) on MF do not separate transaction control from database(or transaction files) management. This is the world of COBOL and its culture.

Few of the other C/S systems come to the new world from the old one. They introduced ORACLE on WinNT/UNIX for server and VB application on Win95/WinNT for clients. But Im afraid that this combination will result in misery especially based on its performance in Japan, because the processing of the Japanese language is overloading and time consuming. In any case, they dont include an order communication module in their system. I believe, however, the middle ware for CPR is necessary to (i) design and construct a true distribution system, (ii) distribute the load of transaction, (iii) ensure the independence of client applications and server applications, and so on. This is the next issue to resolve in Japan.

1.2. trial for object oriented

The trial to develop CPR and HIS with OOP (SmallTalk) and OODBMS was performed in a large-scale university hospital. Unfortunately this project resulted in complete failure. The causes of this failure, in my opinion, are as follows:

  1. No experience of order-entry system in that hospital
  2. Little or no property of system analysis on both sides (hospital and vendor)
  3. Obscure or vague specification

Both sides might be too hasty on their climb towards success. Mother always said me More haste, less speed. Despite this failure, they gained the property now. So, Im looking forward to their next move.

2. Modularity (Best of breed or one-vendor approach?)

Most HIS is constructed by the one-vendor approach, and all of CPR module is introduced by the same approach. For hospitals and clinics, there is no chance to select the best of breed. The reason is the same as described above in the section of Structure/Architecture. In addition, big vendors say our system is designed as an open architecture. This saying may be true, BUT, application interfaces and data format (i.e. DB schema or record layout) have not been opened yet, and this is the truth of today in Japan.

For the future, my guess is that this situation will change rapidly. One reason is the spread of C/S, and another is the establishment of ISO/TC 215.

3. Security

3.1. inside hospital/clinic

identification and certification

Most HIS have only a traditional module which ask for an account and password. Some of them also request an ID card which contains a number or a string of characters in its magnetic strip. This number or string is different from the account, and the end user is NOT notified of this.

I think these mechanisms are almost enough to secure critical data/information inside a hospital, should the staff in a hospital have concerns about security. However, they normally show little concern.

log and audit

Almost all CPR systems record only when, who (i.e. a operator), whose (i.e. a patient), and what data the operator registered. Of course, this data entity is not enough to the audit of access. Access audit has been performed rarely in Japan.

Logs should be recorded as when, who (i.e. a operator), where, whose (i.e. a patient), what data the operator registered, and why, and what data the operator observed. To record Why would provide for a (i) decrease in the difficulty of development of audit programs, (ii) mutual watch inside the hospital when displaying the access history of targeted window or data, and (iii) environment for dynamic control of access.
Such a module will be introduced. Please refer to article #4 on FC2 session, Medinfo98.

policy and rules

Most hospitals do not have a security policy and/or operation rules yet. Therefore JAMI has plans to make them, as described in the previous section entitled What are you going to do next year?.

3.2. for the outside or public network

fire-wall and network topology

Put simply, it varies in each hospital/clinic, from air gap to direct connection to the Internet, according to the security policy and the available budget of each hospital/clinic.

The last year, the working group of the Meeting of Medical Informatics Departments of National University Hospitals has developed the guidelines. The guidelines explains and recommends the necessary functions of a fire wall and the segmentation on a network topology. Most national university hospitals are expected to adopt those guidelines.

encryption and certification

Recently, the working group of network of JAMI has developed the certification and encryption system for clinical data/information exchange over wide area network. This system is based on RSA technology and CA (certification authority) mechanism, but this system excels other secure systems on the following points:

  1. Separation of the inner-hospital certification form the inter-hospital(s) one; this brings about the easiness of coping with certificate management
    • the frequent changes in the staff inside a hospital and the reflection to the outside
    • the responsibility hierarchy inside a hospital (from director to resident/intern)
  2. Adoption of one-time password system with certified time-stamp inside hospital certification
  3. Free from the burden of encryption and signature for end-users inside a secure LAN inside a hospital

These functions solve the problems which has practically prevented the implementation of RSA and CA mechanism for clinical data/information exchanges until today.

4. Patient Identifier

There is NO well-controlled and perfectly unique personal identifier in Japan. This results in both the patient identifier and the staff identifier not being controlled or unique nation-wide. In each hospital/clinic, the combination of the following items are used to identify a patient:

  1. name, gender, birth date, household
  2. insurance number (of the patient or of the head of the patients household)

For a CPR system, an administrator registers a patient and issues an identification number in the system and a patient ID card. It is needless to say that these are not enough to identify a patient perfectly, however we have no option. At most, an administrator refers also to the patients address (and/or the former address). In any case those items may change, so the combination of them is only as circumstantial evidence. All I can say is that I have not heard any trouble occurring due to the patient identifier as of yet, but I know that my saying this has no persuasion.

5. Terminology and Standard Nomenclature

Each hospital/clinic uses their own code systems. Those code systems were prepared based on standards, for example ICD-9, in the beginning of HIS. As time goes on, new items have been added to their code systems by each hospital/clinic, making them unique.

5.1. standards which are often used as a base

  1. For diagnoses or problems: ICD9-based original code systems have been used and some of them are being converted to ICD10-based. SNOMED is registered in optional data field if used, and the main field is filled with ICD. MHW (Ministry of Health and Welfare, Japan) has just created two Japanese standard set of diagnostic terms: (i) the ICD10-based Japanese Standard Diagnostic Terms released from MEDIS-DC for future CPR systems, and (ii) the Japanese Standard Disease Code for Health Insurance Claiming.
  2. For findings or signs and symptoms: Free text entry in general.
  3. For the lab test: JLAC9-based code systems has been used. JLAC has been developed by Japan Society of Clinical Pathology, then JAHIS and MEDIS-DC already decided to adopt JLAC. By the way, JLAC9 (rev. in 1996) has multi-axial structure, therefore, this code system is compatible with LOINC.
  4. For the medicine: We do not have well-controlled code system , so each use their own.
  5. For the medical image: Each use their own, I think. DICOM3-based system had not diffused yet.
  6. For the material supply: Each use their own.

5.2. why hasnt the standardization of terms/codes been achieved in Japan ?

I dont know the true reasons, but I know that the authorities of the government havent intensively compelled hospitals/clinics to use their standard term/code system and its standard doesnt seem to be evaluated enough to use in actual HIS. On the other hand, a few small groups have endeavored to construct standard term/code systems in the Japanese language for many years, but it hasn't been accomplished. One reason is that it seems too large for small groups to carry out. Another reason seems to root from the characteristics of the Japanese language itself:

  1. Letters are classified into phonographical "Kana" and ideographical "Kanji".
  2. Words or terms, especially technical terms are usually represented with a string of "Kanji"s.
  3. Compound or complex concepts or the concept with adjective phrases are represented with many strings of "Kanji"s. The separation of strings, i.e. picking root words, is able to be performed correctly when the semantics of word (i.e. a string) is decided within the context.
  4. In sentences, words and phrases are not separated from each other with white space.
  5. They are often, but NOT always separated with "Kana" or combinations of "Kanas". "Kana" or combinations of "Kanas", i.e. postpositional particle of Japanese language, is used to decide the case of the prior words and phrases, rather than to separate words from each other.

These illustrate the difficulties of morphological analysis. Consequently, the fundamental work of picking up terms from text books or many other documents itself has difficulties for us. Needless to say, classification is the next step following the picking up, and standardization is far away.

Besides, Kanji may also cause a barrier for the standardization of terms/nomenclature. Kanji are ideographical letters@which represent to some extent their meaning within their character, so we are easily but roughly able to imagine the concept of terms/nomenclature. This possibility of easy imagination might have led us to negligence of definition and of standardization. This tends to allow many dialect and dialect may spoil standards.


Q 4. Describe the lessons learned

while developing and implementing the CPR on your continent, including critical success factors as well as failures and the reasons for those failures.

1. Success factors

2. Reasons for failures


Q 5. Identify installations that exemplify the CPR on your continent.

Only the hospitals and/or clinics in Japan are listed in chlonological order. All of them have accepted to be listed in this Questionaire #5.

Sato Hospital

small-scaled private hospital; implemented in 1992; used in the entire hospital; GUI and excellent human interface; patient-centered information system; OPENSTEP is used as platform; developed personally. Kanagawa prefecture; Contact: kiwamu@sato-hosp.or.jp

Ohashi obstetrical/gynecologic Clinic

private clinic; implemented in 1993; outpatient only; GUI and excellent human interface; patient-centered information system; OPENSTEP is used as platform; developed personally. Tokyo; Contact: ohashi@ocean.linc.or.jp

Dental Hospital, Tokyo Medical and Dental University

national univ. hospital; implemented in 1994; used in almost the entire hospital; patient-centered information system; poor CUI human interfaces are improving and newers will be released unitl next March; problems/diagnoses and SOAP has been integrated in the database already; FUJITSU and Sumitomo Electric Industry. Note : NOT a Medical Hospital but DENTAL CLINICS only Tokyo; Contact: sasaki.drad@dent.tmd.ac.jp (Professor/Chairman of Dental Radiology)

Medical Hospital, University of Tokyo

national univ. hospital; implemented in 1994; used in almost the entire hospital; GUI; patient-centered information system; multi-vendor; HL7 has been adopted/implemented already for inter-modules communication. Tokyo; Contact: kohe@hcc.h.u-tokyo.ac.jp (Professor/Chairman of Medical Informatics)

Kameda General Hospital

large-scaled private hospital; implemented in 1995; used in almost the entire hospital; information sharing with other clinics near the hospital; GUI; patient-centered information system; the integration of problems/diagnoses and SOAP is planned to develop unitl the end of this year; Japan IBM and KAMEDA. Chiba prefecture; Contact: toshi@kameda.or.jp (President of the hospital)

Medical Hospital, Kanazawa Medical College

private univ. hospital; implemented in 1997; used in four outpatient departments mainly; GUI; SOAP are not integrated to problems/diagnoses but treated in assessment in SOAP; FUJITSU. Kanazawa prefecture; Contact: oishi@kanazawa-med.ac.jp


Acknowledgment:

I would like to thank Professor Marion Ball and Prof.Hans Peterson for allowing me to represent Japan on the workshop faculty. I look forward to working with such distinguished members as those on the faculty. I would also like to thank Professor Michio Kimura and Professor Shigekoto Kaihara for selecting and recommending me for the faculty of the International Progress on CPR workshop.
I am very grateful to Professor Michio Kimura, Professor Kazuhiko Ohe, Associate Professor Ryuichi Yamamoto, and Professor Hiroyuki Yoshihara for your expertise and advice. And Many thanks to Mr. Yamashita and Mr. Asonuma (FUJITSU), Mr. Iwanami (NEC), and Mr. Tanaka (Japan IBM) for your help in informing me of the current state of matters relating to CPR in Japan today.
Finally, thanks to Ms. Kimblern for your advice on my English.


mailto: Prof.Hirose