医療情報分野における標準化の動向 と Ruby 言語による実装

Movement on medical standard and its implementation by Ruby

小林慎治；　愛媛大学医学部第一内科Shinji KOBAYASHI; Ehime University

Who am I?Why do I use Ruby?

Agenda

e-Health care in Japan and My bibliography

Era E-Health in Japan My bibliography

1970Happy Origin

Start for research Born in Saga Japan at April 19, 1970

1980Hopefuldevelopment

'Receipt computer'Claiming system for insurance

Manga, Anime, ComputerMedical student/ Kyushu University

1990Painful growth

Clinical Physicians Order / Entry system

MD license, 1995Resident, Clinical hematology/oncology

2000Explosion

Electronic medical record/Electronic health record, full digital

PhD. research and development on OSS in medical field

I can do it better!

Why do I use Ruby?

Cost to change brain mode Lower cost Short time

Open source software Free to use, financially, politically

Object Oriented Programing Language Next challenge

To learn innovative skill of software Experimental, research use

Health care environment of Japan

Total health insurance system To provide average level health care to all nations.

Universal access When, Where, Who, What

High cost performance Low cost Longest life span Minimal level maternal/infant mortality

Japanese Medical Insurance System From a patient and a medical perspective

All citizens are able to join one insurance system Free access to providers and specialists Fee-for-service payment Providers must submit claims for processing by the

10th of the month following the visit. Co-payments collected by providers each visit Each prefecture and county-level government, as

well as cities, towns and villages, has its own individual system of additional subsidies for medical care payments.

Average life span and infant mortality rates are among the best in the world!

Health expenditure/GDP

'Receipt' claim form

Demographics Insurance number Diagnosis Laboratory test/exam Procedure Prescription Many local rules

'Receipt computer'

Claiming/billing application Calculate medical claim under complex rule Print out 'Receipt'

Database Patients' demographics

Name, birthday, insurance Disease, drug, procedures

Proprietary Data can be utilized for only 'Receipt' work

Problems of e-Health (in Japan)

High cost, Low investment Oligopoly market Suppression to raising cost for health care

Many standards, few implementation 'Paper' standard, restriction to use 'Proprietary' standards

'Lock in' Vendor lock in → Oligopoly Data lock in → absence of reusability

How many patients? Disease outcome?

AYDBTU?

VENDOR: ALL YOUR DATA ARE BELONG TO US!?

OSS

Open license, free distribution Share intellectual resources

Avoid 'lock in' Health data has long life time as Human. Assurance for future availability

Drives open standard Reference implementation accelerate 'OPEN'

standard Cost reduction

Not aim, but result.

ORCA Project

JMA Standard Receipt Computer OSS, under GPL 2.0(translated into Japanese) Avoid 'lock-in'

Standard Implementation based 'de facto' MML/CLAIM protocol ↔ EMR

Collect data Health care policy based data against meaningless

government policy

Grace Murray Hopper

16

Adoption of ORCA

17

Adoption of ORCA（May 2002 ～April 2010）

17

Working・・・8800

Preparing・・・1145

Planning・・・ 498

　

【specification】　

　・OSS＋Billing software, morethan 1M steps　・Process 1T JPY( 10B USD) claims/year　・Only 2 week for adjust new rules/2years

Made in Matsue

OSS2010, Notre Dame, USA

OSS2010, Notre Dame, USA

MOSC2010, Kuala Lumpur

MOSC2010, Kuala Lumpur

Open Source EHR Summit, 2012

Problems on medical standards

Many standards, few implementations About 250 standards 'Proprietary' standards

Lack of interoperability Not accessable 'Connectathon' Harmonization not sound cooperatively

Political flames Academics, Commercialisms,....

Too many inquiries Too greedy

2011/12/14 CIMI press release

● CIMIとは– 臨床情報モデリングイニシアティブ(CIMI; Clinical

Information Modeling Initiative)は、健康に関する記録やメッセージ文書として作成され保存される情報が意味論的に相互運用可能なものとなるために、健康情報の内容を表現する共通形式についての詳細な仕様を提供するための国際的な共同研究である。（2011年7月から活動）

● 2011/11/29-12/1 London meeting– グループとしての基本方針

Principle

● CIMI specifications will be freely available to all.

● CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML).

● 3. CIMI is committed to transparency in its work product and process.

Approach

● ADL 1.5 will be the initial formalism for representing clinical models in the repository.

● CIMI will use the openEHR constraint model ● A set of UML stereotypes, XMI specifications and transformations

will be concurrently developed using UML 2.0 and OCL as the constraint language.

● A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.

● Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.

Clinical modelingとは

● 臨床概念の明確化– 集めるべき情報は何か。項目はどれか。– 「血圧」と言う場合に考慮されるべき情報は何か

● 臨床概念の構造化– 概念同士の関係を明らかにする– オントロジー、シソーラス

● 臨床概念の結合– ユースケースに合わせて必要に応じて概念を組み

合わせる(CDA-RIM, Archetype-Template)

The openEHRProject

Features of the openEHR

Open Source implementation based standard Free to use Not paper based standad Reference implementation

Eiffel, Java, C# Two level modeling

Separate clinical domain concept from technical architecture

Archetype model/reference model

Semantic interoperability of healthcare information

Semantic interoperability

One record, multiple use Health care provider

Clinical use, history presentation Government

Public health Researcher

Clinical trial Domain authorized concept model

Computer processable Domain experts authored

Known difficulties

Multiple inheritance

Single inheritance+mixin(implementation)

ISO8601_DATE

rm::support::assumed_library

ISO8601_TIME

ISO8601_DATE_TIME

ISO8601_Date_Time+year+month+day+hour+minute+second+fractional_second+as_string

ISO8601_Date+year+month+day+as_string

ISO8601_Time+hour+minute+second+fractional_second+as_string

Module = Class - constructor

Class = Module + constructor

ISO8601_Date_Module+year+month+day+as_string

ISO8601_Date+initialize

ISO8601_Time_Module+hour+minute+second+fractional_second+as_string

ISO8601_Time+initialize

ISO8601_Date_Time

+initialize+as_string

ISO8601_Date_Module

+year+month+day+as_string

ISO8601_Time_Module

+hour+minute+second+fractional_second+as_string

a

mixin

Circular import

A.java

import Bpublic class A

B.java

import Apublic class B

ab.rb

class A

end

class B

end

a.rb

require Bclass A

b.rb

require Aclass B

SupportData TypesData StructuresSecurity Commo

n

Composition Archetype profTemplate OMIntegration

Integration

DemographicEHR

EHR

AOM ADL

Language AM RM TotalEiffel 10,145 8,258 18,403C# 5,472 17,488 22,960Java 11,603 3,642 15,245Ruby 945 3,358 4,303

Effective steps of libraries

Magic of Duck typing

ADL Parser

Archetype Definition Language Portable domain specific language Concept describing language Ontology based data definition

Grammatical issues Partially left recursive Lexical traverse

cADL, dADL

Parser algorithm

LALR(1) Most popular implementation Grammatical flexibility Exponential computing cost

LL(k) Classical simple way Grammatical restriction

PEG/Packrat LL/Memoize, best performance

Packrat ADL parser implementation

Algorithm Packrat/PEG

Grammar Convert yacc type LALR(1) rule to PEG Remove left recursion

A → A α1∣⋯∣A αn∣β1⋯∣βmA →β1 A ' ∣⋯∣βm A'A ' →ε∣α1 A '∣⋯∣αn A '

Parser benchmark

Impact Download

More than 2,300(70/version) GitHub

1fork, 8watchers

How to install

gem install openehr

How to use

require 'openehr'

parser = ADLParser.new(adl_file)archetype = parser.parse

Mission

ADL Validator ADL Serializer Rails

generator for erb template, migration, controlle 15min EHR!

Archetype flattener, etc, etc Education of Object Oriented technology for

medical informaticians

Discussion

Ruby proved its capability to implement openEHR specification with known implementation problems.

Programming steps could be reduced, but efficiency for EHR development needs another study.

Runtime performance is a known deficit of Ruby. Our benchmark tests also proved lower performance than Java runtime, but it was within the tolerable speed.

ページ 1ページ 2ページ 3ページ 4ページ 5ページ 6ページ 7ページ 8ページ 9ページ 10ページ 11ページ 12ページ 13ページ 14ページ 15ページ 16ページ 17ページ 18ページ 19ページ 20ページ 21ページ 22ページ 23ページ 24ページ 25ページ 26ページ 27ページ 28ページ 29ページ 30ページ 31ページ 32ページ 33ページ 34ページ 35ページ 36ページ 37ページ 38ページ 39ページ 40ページ 41ページ 42ページ 43ページ 44ページ 45ページ 46ページ 47ページ 48ページ 49ページ 50ページ 51ページ 52ページ 53ページ 54ページ 55ページ 56ページ 57ページ 58