Download as pdf or txt
Download as pdf or txt
You are on page 1of 10

Special Session "Social System Design" - Health, Medical Care, Welfare and Housing Refurbishment,

UD-2006 (2nd Int’l Conf. On Universal Design in Kyoto 2006),


International Association for Universal Design, Kyoto, Oct. 22 – 26, 2006

Universal Design Aspect of Human Resource Development Program for


Secure Information System Designers
- Case Study on a Customized Medical Care Support System Design -
Satoshi Ono1, katsumi Konishi1, Akihiro Fujii1 and Yasushi Matsumoto2

1 Faculty of Informatics, Kogakuin University, Shinjuku-ku Tokyo 163-8677 JAPAN


2 Intelligent Systems Laboratory, Secom Corp., Mitaka-shi, Tokyo 181-8528 JAPAN

ABSTRACT
Next social information infrastructures are expected to provide convenient and secure services to
widest range of possible users. In addition, they should be conformant to related standards and
regulations. Engineers with design and development skills for above-mentioned systems are quite
demanding, and Kogakuin-university launched a human resource development project for secure
information system designers in 2003. It is a once-a-week program for part-time students, and features
PBL (Project Based Learning). In 2005 PBL, a customized medical care support system had been
designed. This paper explains outlines of the program, featuring PBL activities, and evaluates resultant
students’ designs of 2005 PBL, from four viewpoints; namely, functional design, information security,
regulatory compliance and information accessibility.

KEYWORDS
information security; information accessibility; regulatory compliance; ICT engineer

1. INTRODUCTION
Nowadays, some information systems work as social infrastructures and our daily lives are deeply
dependent on them. These systems are expected to provide convenient and secure services to widest
range of possible users. In addition, they should be conformant to related standards and regulations.
The goals, however, cannot be easily achieved. In order to alleviate the problems, Japanese
government has established strategic plans such as "e-Japan" (Electronized and Comfortable Japan)
priority policy program(ITSHJ 2002) and IT new reformation strategy(ITSHJ 2006). In order to develop
fundamental IT infrastructures, these strategic plans promote four activities; IT society having no
"Digital Divide", safe and comfortable environment for IT usage, human resource development
(hereafter called HRD) and R&D on them. Engineers related to the fields are quite demanding. For
example, Ministry of Internal Affairs and Communications, Japan estimates that shortage of security
engineers and advanced ICT engineers amounts to 120 thousands and 200 thousands, respectively (MIC
2005). Under such background, Kogakuin-university launched a HRD project † for advanced secure
information system design engineers in 2003. The objectives of the program include:
- Training central core engineers eligible to analyze, design and implement secure social information
systems conformant to related standards and regulations.
- Developing systematic curricula and teaching materials essential to designing such systems.
This HRD program is a once-a-week course for part-time students and graduate students. The
course consists of lectures, exercises and features PBL (Project Based Learning). The PBL is a group-
based practical training program; 7 to 8 students form a group, and each group is requested to actually


This project has been fully supported from 2003 by the human resource development support
program for newly risen fields, Science and Technology promotion/coordination program, operated by
Ministry of Education, Culture, Sports, Science and Technology, Japan.

1
analyse and design a roughly specified social information system. In 2005 academic year, the theme of
PBL is a customized medical care support system utilizing personal genomic information. This paper
explains outlines of this HRD program, especially featuring PBL activities, and also evaluates
resultant students’ designs of the 2005 PBL from following four viewpoints:

Functional Design: An information system should clearly state the system scopes and
objectives, and should provide users with necessary services for achieving the objectives.
Information Security: An information system (including designer, operator) should establish
and maintain reasonable procedures to protect the confidentiality, integrity and availability
of sensitive data in the system and networks.
Regulatory Compliance: An information system should comply with applicable regulations
and guidelines for security, accountability auditability and so on.
Information Accessibility: An information system should provide services and privacy with
widest range of possible users including older persons and persons with disabilities. In
addition, user operations and system responses should be simple, intuitive and flexible.

2. ADVANCED SECURITY ENGINEER HRD PROJECT


2.1 Project Overview
As described in Section 1, Kogakuin University launched Advanced Security Engineer HRD Project in
2003. The teaching course has been opened since May 2004. The goal of this project is to train
engineers to the level that he or she can design social information systems, considering security
requirements for all system lifecycle phases; namely analysis, design, test, deployment, operation and
audit phases. This project features (1) intensive cooperation between industry and the academic world
and (2) Project-based Learning.
In general, it is difficult to develop sophisticated business practices only in the purely academic
world. In contrast, it is also difficult to develop fundamental and systematic knowledge only with
OJTs (On-the-Job Trainings) in industrial world. To overcome the difficulties, lecturers of this course
have been selected from diverse backgrounds: 14 lecturers from 7 universities, and 10 lecturers from
cooperated industrial organizations such as IPA (Information-Technology Promotion Agency, Japan),
JNSA (NPO Japan Network Security Association) and famous Japanese private companies. The
course of academic year 2005 is summarized as follows:
Management Organization: Kogakuin University
CPD (Continuing Professional Development) Center
Students: 46 (43 part-time students, 3 graduate students)
Opening Period: From the middle of May, to the end of November
Every Saturday, 6 hours/day.
Total Teaching Hours: 168 hours
Number of lecturers: 24
Lecture Categories:
 Secure System Design Architecture
 System Deployment and Operation Security
 Regulations and Application Domain Specific Knowledge
 Information Service Fundamentals
 Information System and Security Fundamentals
Practical Trainings:
 Secure Network and Server Design
 Security Protocol Analysis
 ISO 15408 Security Target Design
Project Based Leaning:
 Secure Network and Server Design
 7 ~ 8 students per group
 Daily Discussion using mailing lists and bulletin boards

2
 Group presentation in once a month (3 hours /month)

2.2 Project Based Learning


The PBL has two phases; an investigation phase, and a design phase. In the investigation phase,
students are requested to list-up relevant technical issues and make discussions in class. Then, several
investigation themes are allocated to each group overlapping, so that each theme is duplicatively
allocated in several groups. Investigation reports are presented three-times in the class hours, so that
all students can share resultant knowledge on every investigation theme. In this phase, preparatory
works such as risk analysis, data modelling and security level classification, are also performed.
In the design phase, each group is given rough specification of the target system and requested to
make a design proposal for it. The document template for proposals is shown in Table 1. Note that the
template includes not only items for system design, but items usually found in RFP (Request for
proposals). It is because security features should be considered in very early analysis phases.

Table 1. A Template for System Design Proposal Documents


1. Introduction
6. System Security
1.1 System Purpose
6.1 Administrative Procedures
1.2 Proposal Summary
6.2 Physical Safeguards
2. Overall Description
6.3 Technical Devices and Mechanisms
2.1 System Overview and Features
7. Development Plan
2.2 System Functions
7.1 Schedule Estimate
3. System Components
7.2 Cost Estimate
3.1 Software
8. Operation Formation and Responsibility
3.2 Hardware
9. ROI (Return of Investment) Analysis
4. Performance Estimation
10. Remaining Problems
5. System Scalability and Expandability

3. CUSTOMIZED HEALTHCARE AND MEDICAL CARE SUPPORT SYSTEM


3.1 Target System Overview
In this section, we explain the 2005 PBL target system, i.e. a customized medical care support system
utilizing personal genomic information.

Laboratory Related Call Center


Service (Nurse)
Health
Insurance
Pharmacy/ IIHI Data
Drug Store Medical Info. Support Provider
Service Provider (SSP) Genomic
User/ IAAA Info DB
Patient Management
Medical
Subsystem Info DB

Medicine
Data Medicine Genomic
Hospital Applicability DB Medicine DB
Clinic Provider

IAAA: Identification, Authentication, IIHI: Individually Identifiable


Authorization and Accountability Health Information
Fig. 1 A customized medical care supporting system
utilizing personal genomic information
Concept diagram of the system is shown in Figure 1. This system connects various stakeholders
of healthcare and medical care services. For examples, hospitals, drug stores, health insurances and

3
call centers are connected. There also exist data provides which manage personal and permanent data.
The most sensitive data are called IIHI (Individually Identifiable Health Information), which include
Medical Info DB (personal information on healthcare and medical treatment) and Genomic Info DB
(personal genome data). There exist several regulations for handling IIHI (US-HHS 2000), (US-HHS 2006),
(OHSMT 2005) Medicine data include Medicine applicability DB and Genomic Medicine DB. The
former stores symptoms and applicable medicine information. The latter stores applicability and side-
effect data of medicine based on genomic patterns. The support system also has an IAAA management
subsystem. IAAA stands for Identification, authentication, authorization and accountability. These
features are used for system access control to protect patients’ privacy.

The objectives of this 2005 PBL are:


 Design an information system that can securely manage personal genomic information
and healthcare / medical care information.
 Design service workflows among major stakeholders (Hospital, Drug stores, and so on)
and users of the system (Patients, Doctors, Nurses and so on).
 Design a seamlessly integrated system of medical services and information services. The
system should be able to provide necessary services to widest range of possible users in a simple
and intuitive way.

The major goals of the PBL are:


 Analyze functional requirements of a system satisfying above objectives.
 Analyze system risks. Then, design and evaluate necessary countermeasures for the risks.
 Make a design proposal for the system that qualifies to be presented to competent authorities
Note that in 2005 PBL, the program weighs rather on system functionalities and security.
Universal design or information accessibility requirements are derived from major possible users of
the healthcare/medical care system, namely older persons and persons with disabilities.

3.2 Technical Challenges


The customized medical care system mentioned above is technically challenging in following points:
 It must provides dependable and easily accessible daily healthcare / medial care support service
for mass users including older persons and persons with disabilities. Standardized methods would
be preferable as long as possible. For example, there exist standards and guidelines on
accessibility in general (CUD-CD-UCSU 2006), (ISO-G71 2001), (JIS-X8341-1 1994) or for specific areas
such as Web contents (Chisholm, W., Vanderheiden. G. and Jacobs, G. (eds.) 1999), (JIS-X8341-3 1994) and
application programs (Vanderheiden, G.C. 1994).
 It must have capability to handle highly sensitive regulated information such as IIHI. In order to
satisfy regulations(US-HHS 2000), (US-HHS 2006) , conformant solutions need to implement ID/role
management, authentication, access control, data encryption and anonymization as well as
monitoring and auditing functionalities (DCID-6/3 2000), (Sun BWP 2004).
 It must provide dependable record management (US-FDA 2003), namely long-term data
preservation and falsification prevention. It must also take measures for disasters.
 It must conform to various medical and pharmaceutical regulations and guidelines (METI-JP
2004),(MPB-MHLW-JP 2006),(MPB-MHLW-JP 2005).

4. DESIGN PROPOSAL EXAMPLES CREATED IN PBL 2005


4.1 Investigation Phase Themes in the PBL 2005
As noted in Section 2.2, students were given investigation theme, and had requested to make
presentation on them. Followings are theme list classified by categories
Information Security:
 Privacy-Enhancing Technologies (PETs)
 PKI/ID federation
 Long-term electronic data preservation and record management

4
Domain-specific knowledge and standards:
 Electronic data representation of personal genomic information carried on DNA
 European standardization of health informatics (CEN/TC 251)
 Intellectual property rights on genome
 Related venture business and advanced projects
Regulatory compliance:
 Personal Information Protection Act and related legal regulations
 Legal regulations on medical consultation, prescription and external medical data preservation
 Personal genomic information protection guideline
Preparatory design analysis:
 Risk analysis and countermeasures
 Data modelling and security classification
As shown above, there exist no investigation themes directly related to Information Accessibility.
Most proposals, however, consider information accessibility to some extent. We show some of them in
the next section, and evaluate them in Sections 5 and 6.
4.2 Proposal examples created in Design Phase of the PBL 2005
Followings figures are created consulting achievements of PBL 2005. Note that following figures are
not representing specific design of one group, but a design integrating good points of achievements
found in PBL 2005 design documents.

Drug Store (1) A patient comes to a Call Center


(Remote Prescription Drug Store, and starts (Reception
Terminal) remote medical consultation Terminal)
using Videophone, nurse
patient MCU
Vital Prescription (2) A Call Center
Sensors Medical Info. provides primary care
SSP service for inbound
(5) The patient can obtain calls from authorized
prescribed medicines. customers

(4) A medical doctor


Hospital Medicine Data IIHI Data
examines the patient,
(Medical Provider Provider retrieves health
Consultatio (3) A Hospital provides information and
n Terminal) medical service on makes a prescription.

Doctor reservation and


MCU: Multipoint Control Unit
emergency basis
for Videophone
Videophone connection
Fig.2 Typical Workflow of Remote Medical
General Data Connection
Consultation

Figure 2 shows a typical workflow of remote medical consultation. A patient goes to a drug store
and logs into a remote prescription terminal using an IC identification card. The terminal has
videophone function, and is connected to the call center reception terminal. The communication is
done securely using encryption. A nurse at the call center provides primary care service, and forwards
calls to a doctor in a hospital if necessary. The doctor examines the patient, retrieves related DBs, and
makes a prescription if required. The prescription is transferred to the drug store terminal, and is
printed in a watermarked paper. The patient can buy the prescribed medicines at the drug store.
Typical workflow of medical care using genomic information is as follows: Related entities are
shown in Figure 3. When a doctor (or a patient himself in self-medication case) logs into the terminal,
UID is used for authentication. When access is permitted, the Medical Care Subsystem retrieves the
medical info DB of the patient, and searches Medicine Applicability DB for obtaining candidate

5
medicines. Then, Genomic Medicine DB is accessed for retrieving problematic genomic patterns on
each medicine. Then the patterns are passed to the Genomic Information Subsystem for matching the
patient’s genomic information. The result is used for medicine selection.

Frontend Medical Care Genomic Info.


Subsystem Subsystem Subsystem
General Zone Security Zone A Security Zone B
User Terminal General Business (Medium Level) (High Level)
Data Processing ID Mapping ID Mapping
UID UID (UID) / IID(A)) (IID(A) / IID(B))
Identified IID(A)
by UID Identified Identified
UID by IID(A) by IID(B)
IAAA Medicine
ID Card Data Applicability DB Medical Genomic
Info DB Info DB
User Genomic
(Anonymized) (Anonymized)
Preference Medicine DB
Fig. 3 Zoned and Anonymized Info. Management Scheme
Special consideration is taken to provide privacy of patients' genomic data, using two-level
Linkable Anonymization technology, so that even a system manager of one security zone cannot
directly access identifiable personal genomic information. (Note that the proposed system assumes
that each security zone has a distinct system manager.) As shown in Figure 3, three Identifiers are
used, namely UID, IID(A), and IID(B). These IDs are mutually related (linked) and can be translated
into the linked ID. A user (or a doctor representing the user) logs into the terminal using UID. The
IIHI in the Medical Care subsystem is indexed using IID(A), and the link information between UID
and IID(A) is rigidly access-controlled. For accessing identifiable personal genomic data, IID(A) is
further mapped into IID(B) and this ID is used as an access key to the Anonymized Genomic
Information DB.
Figure 4 shows a design of Drug Store Remote Prescription Terminal and a Call Center Terminal.
The Drug Store Remote Prescription Terminal features a touch panel, a videophone camera, a
prescription printer, vital sensors and a secure ID card reader. These terminals can connect to MCU
(Multipoint Control Unit) for creating multi-party videophone including medical consultation
terminals in hospitals.

A Touch Panel
A Videophone Doctor’s
Face-to-face
Camera Diagnosis
Examination of
For Remote shown in a Web
a Patient using
Examination Browser
Videophone
Window

A Secure ID
Card Reader

Vital Sensors A Prescription Printer


(using Special
Watermarked Paper)

Drug Store Remote Prescription Terminal Call Center Terminal

Fig. 4 Design Overview of a Remote Prescription System Terminal

5. SYSTEM DESIGN EVALUATION POINTS AND EVALUATION RESULTS


We will briefly evaluate the PBL students' design from viewpoints of information security, regulatory
compliance and information accessibility.

6
5.1 Evaluation Points
(1) Functional Design (IEEE-Std-830 1998)
 [F1] System overview: e.g. objectives, scopes, design strategies, constraints and architecture.
 [F2] Subsystem design: e.g. functional requirements and interfaces
 [F3] System service design: e.g. requirements and workflows
 [F4] User interface design: e.g. graphical user interface design and report layout design
(2) Information Security
Strategic System Design:
 [A1] Well-defined roles, attributes and responsibilities for persons of decision-making,
operations and general users.
 [A2] Well-defined data classification (level-of-concerns for confidentiality, integrity and
availability) based on risks and values.
 [A3] Well-defined administrative policy and procedures for IDs, roles, attributes and access
authorization data including creation, activation, modification and termination.
 [A4] Well-defined protection policy and procedures for processing data based on data
classification level. The term “processing” includes (but not limited to) creation, acquisition,
retrieval, modification, copy, preservation, transmission and deletion,
 [A5] Well-defined subsystem-level security requirements and administrative procedures
including physical safeguards, security mechanisms/devices, connecting networks, certification
and accreditation process and internal/external auditing, based on maximum data classification
level in the subsystem and least-qualified system users.
 [A6] Well-defined subsystem-level requirements and administrative procedures for system
redundancy, configuration management, backup/restoration, timestamping and maintenance based
on maximum data classification level in the subsystem.
Technical System Design:
 [B3] - [B6]: Conformant mechanisms corresponding to policies, restrictions and procedures
defined in [A3] – [A6] above, respectively including effective execution, enforcement,
monitoring, alarming, reporting and auditing functions.
Deployment and Operation:
 [C1] Physical area, equipment and media and print-out protection conforming [A1] – [A6].
 [C2] IDs accounts, and authorization data management conforming [A1] – [A6].
 [C3] Network and system configurations conforming [A1] – [A6].
 [C4] System operation, monitoring, auditing and maintenance conforming [A1] – [A6].
 [C5] Security training, education and awareness for general and specialized responsibilities.
(3) Regulatory Compliance
 [R1] Protected Health Information (PHI) is clearly identified and classified consistently.
 [R2] Special technical / procedural consideration is made for highly classified PHI.
(e.g. only anonymized data are used for research and statistical process purpose,
 [R3] Usage or disclosures of PHI to routine works are limited to minimal for the purpose.
Routine works include treatment, payment and normal business operations and should be defined
in "Notice of Privacy".
(4) Information Accessibility
We have focused our attention to the following three principles among Seven Principles presented by
North Carolina State University's Center for Universal Design:
1. Equitable Use: The design is useful and marketable to people with diverse abilities
2. Flexibility in Use: The design accommodates a wide range of individual preferences and
abilities.
3. Simple and Intuitive Use: The design is easy to understand, regardless of the user's experience,
knowledge, language skills, or current concentration level.
In addition, there exist two approaches to universal design:
Direct Access: Provisioned and implemented in system functions.

7
Assistive Access: Locally customizable using external assistant devices available, or systems adhere
to contents accessibility standards / style guideline.
For evaluation of Information accessibility, we will focus the discussion on the design
consideration of Drug Store Medicine Prescription Terminal.
We have evaluated the conformance to the principles above in following points:
 [U1] Equitable use features for menu selection and service navigation function, especially
provision for aged person and person with impairments in vision or hearing.
 [U2] Equitable use features for user authentication, especially, PIN input device for person with
visual impairments.
 [U3] Equitable use feature for videophone-based services providing remote medical
consultation and medicine prescription service, especially one-hand operation capability and
provision for a person with hearing impairments.
 [U4] Selectable alternatives for all visual/auditory information provided by the terminal.
 [U5] Design consideration for terminal customizability using Assistive Technology
 [U6] Simple and intuitive use of user interface and dialog design

5.2 Evaluation Results of Students’ Design


In 2005 PBL, there were six groups in class, and each has developed design documents for the same
target system, namely, a customized medical care support system. The design document of each group
is evaluated in points described above, and classified from A to D. The score 10, 8, 5 and 0 is given
for them, respectively. The evaluation results are summarized in Figure 2. (In the figure, “-“ stands for
“D”. We will omit the detailed evaluation basis.
As shown in Figure 2, most groups, in general, perform rather well in many points. There were
few students who had actual experience in medical system designs. Students had applied knowledge
obtained through lectures of the program, and they investigated related topics from Internet by
themselves. There exist, however, several evaluation points where average scores of all groups are not
higher than 5.0. This means that average group performance was lower than required level. As shown
in Figure 2 above, there are six such points. Covering these topics more intensively may further
enhance the program. We discuss shortly for each point.

Table 2. Evaluation Results of PBL System Design


Information Security
F: Functional R Regulatory U: Information
Design A: Strategic B: Technical C: Deployment
Compliance Accessibility
Design Design & Operation
1 2 3 4 1 2 3 4 5 6 3 4 5 6 1 2 3 4 5 1 2 3 1 2 3 4 5 6

G1 B C C - C C C C C B - C B B B - B C C B C C C - C - - -
G2 B C C C C A C C C C - C B B B C A B - B B - C - C - C -
G3 A A A B C A B C C C C C B B A C B B - B B C C - C - C B
G4 A B A B C A B C C C - B B B A B A A C B B C C - C C B B
G5 B B C - B C B B B B B C C B B B B B B B B B C - C C B -
G6 A B A A C A B B B B B B C B B C B B B B C C C - C - C B

9.0 7.3 7.5 5.2 5.5 8.3 7.0 6.0 6.0 6.5 3.5 6.0 7.0 8.0 8.75.2 8.7 7.8 4.3 8.0 7.0 4.7 5.00.0 5.0 1.7 5.2 4.0
Score
7.3 6.6 6.1 6.9 6.6 3.5

[B3] Technical design for managing identities and access authorization data in the system:
All groups had assumed availability of PKI authentication infrastructure such as HPKI and JPKI.
Most groups, however, lacked in discussion of how internal principals (role or attribute) should be
maintained, and how access control list for classified data should be managed and audited for
conformance to the system security policy.

8
[C5] Security training, education and awareness for general and specialized responsibilities:
The PBL itself is security training for designers, and students might have considered security
training as a matter of course. Actually, security trainings for business users and general customers
tend to be significantly different from those for system designers, and should be considered carefully.
[R3] Minimal usage or disclosures of PHI to routine works:
The PBL had not made detailed system/business analyses that would be executed preceding
system design phase. It is mainly because the PBL project is “a virtual project” that does not have real
business nor real users. Thus, it would be difficult for students to define “routine works” explicitly
where no business activities were actually conducted.
[U2] PIN input device for person with visual impairments:
Touch pad is known to have problems for PIN input securely for visually impaired person.
Typically, telephone-like button pad is used for this purpose. No groups have mentioned it, however.
[U4] Selectable alternatives for all visual/auditory information:
Two groups use a standard Web browser for user interaction. There exist standardized web content
accessibility guidelines. They define contents design method for providing alternative information by
user preferences. Other groups do not mention methods, or explicitly define vendor-specific methods
where no such guidelines exist. Vendor-specific methods are adopted mainly because maintainability
and security. This may be design trade-offs, where we should intensively coordinate them properly.
[U6] Simple and intuitive use of user interface and dialog design
Three out of six groups have shown GUI samples, which took into account of aged users.

6. CONCLUSION
This paper has introduced and evaluated the human resource development project for secure
information system design engineers conducted by Kogakuin University Japan from 2003. This
program is a once-a-week part-time student project and features PBL (Project Based Learning). In
2005 PBL, a customized medical care support system had been designed. This paper has evaluated the
outcomes of the PBL, form viewpoints of functional design, information security, regulatory
compliance and information accessibility. In some cases, enhancing security causes difficulty in
information accessibility. Further intensive coordination of security and universal design principles
would be required for achieving dependable social information infrastructures.

ACKNOWLEDGEMENTS
We are grateful to Prof. Eiji Yodogawa and Prof. Nobuya Nakazawa of Kogakuin University for
helpful discussion and guidance for the operation of the program. We also thank to Yoichi Tao, Senior
Consultant of Secom Corp. Japan for supervising the PBL project and valuable discussion in this
research.

REFERENCES
Chisholm, W., Vanderheiden. G. and Jacobs, G. (eds.) 1999. “Web Content Accessibility Guidelines
1.0”, W3C Recommendation 5-May-1999 (http://www.w3.org/TR/WAI-WEBCONTENT/)
CUD-CD-UCSU 2006. "Universal Design Principles", Center for Universal Design, College of
Design, North Carolina State University (http://www.design.ncsu.edu/cud/about_ud/udprinciples.htm)
DCID-6/3 2000. “Protecting Sensitive Compartmented Information within Information Systems”,
DCI Directive 6/3, Director of Central Intelligence United Sates
IEEE-Std-830 1998 “IEEE recommended practice for software requirements specifications”, Standard
830, Software Engineering Standards Committee of the IEEE Computer Society
ISO-G71 2001. “Guidelines for standards developers to address the needs of older persons and persons
with disabilities”, ISO/IEC Guide 71, International Organization for Standardization

9
ITSHJ 2002. "e-Japan Priority Policy Program 2002", IT Strategic Headquarters, Japan
(http://www.kantei.go.jp/foreign/policy/it/0618summary/01_e.html)
ITSHJ 2006. “New IT Reform Strategy”, IT Strategic Headquarters, Japan
(http://www.kantei.go.jp/foreign/policy/it/ITstrategy2006.pdf)
JIS-X8341-1 1994. “Guidelines for older persons and persons with disabilities -- information
communication equipment, software and services -- Part1: Common Guidelines”, X8341-1, Japanese
Industrial Standards
JIS-X8341-3 1994. “Guidelines for older persons and persons with disabilities -- information
communication equipment, software and services -- Part3: Web Content”, X8341-3, Japanese
Industrial Standards
Kogakuin 2006. “The human resource development project for secure information system design
engineers”, (in Japanese) (http://www.cpd.kogakuin.ac.jp/)

METI-JP 2004: "Privacy Guidelines for Personal Genomic Information Industries", Ministry of
Economy, Trade and Industry, (in Japanese) METI notice No.435
(http://www.meti.go.jp/press/20041217010/041217iden.pdf)
MIC 2005, “MIC-leaded Activities on ICT Human Resource Development”, (in Japanese)
Information and Communications Bureau Ministry of Internal Affairs and Communications (MIC),
JAPAN (http://www.soumu.go.jp/joho_tsusin/policyreports/chousa/jise_ip/pdf/050317_1_s1.pdf)
MPB-MHLW-JP 2006: “Amendments for Privacy Guidelines for Medical, Care Industries”,
Official Notice 0421006, Medical Politics Bureau, Ministry of Health, Labor and Welfare
Japan (in Japanese) (http://www.hospital.or.jp/pdf/15_20060421_01.pdf)
MPB-MHLW-JP 2005: “On the interpretation of Medical Doctor Act Section 17, Dental
Doctor Act Section 17 and Health Nurse, Midwife and Nurse Act Section 31”, Official Notice
0726005, Medical Politics Bureau, Ministry of Health, Labor and Welfare Japan (in Japanese)
(http://www.hospital.or.jp/pdf/15_20050726_01.pdf)
OHSMT 2005: "Information Security Standards (V2.0)", Order-made health-care services and medical
treatment optimized for each individual project (http://biobankjp.org/plan/security.pdf)
Sun BWP 2004. "Achieving HIPAA Compliance With Identity Management from Sun", A Business
White Paper (http://www.sun.com/software/products/identity/wp_hipaa_identity_mgmt.pdf)

US-FDA 2003. “Electronic Records; Electronic Signatures”, Title 21 Code of Federal Regulations (21
CFR Part 11) US Food and Drug Administration (http://www.fda.gov/cder/guidance/5667fnl.htm)
US-HHS 2000. "Standards for Privacy of Individually Identifiable Health Information; Final Rule" US
Department of Health and Human Services (http://www.hhs.gov/ocr/part1.pdf)
US-HHS 2006. "HIPAA Administrative Simplification", US Department of Health and Human
Services (http://www.hhs.gov/ocr/AdminSimpRegText.pdf)
Vanderheiden, G.C. 1994. “Application Software Design Guidelines: Increasing the Accessibility of
Application Software to People with Disabilities and Older Users",
(http://trace.wisc.edu/docs/software_guidelines/software.htm)

10

You might also like