Ruby Movement on - - PowerPoint PPT Presentation

医療情報分野における標準化の動向 と 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 1970 Happy Origin Start for research Born in Saga Japan at April 19, 1970 1980 Hopeful development 'Receipt computer' Claiming system for insurance Manga, Anime, Computer Medical student/ Kyushu University 1990 Painful growth Clinical Physicians Order / Entry system MD license, 1995 Resident, Clinical hematology/oncology 2000 Explosion 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 openEHR Project

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

• f 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_Tim e +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 B public class A B.java import A public class B

ab.rb class A end class B end

a.rb require B class A b.rb require A class B

Support Data Types Data Structures Security Commo n Composition Archetype prof Template OM

Integratio

n

Integratio

n

Demographi c EHR EHR

AOM ADL

Language AM RM Total Eiffel 10,145 8,258 18,403 C# 5,472 17,488 22,960 Java 11,603 3,642 15,245 Ruby 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⋯ ∣βm A →β1A '∣⋯ ∣βm A' A ' →ε∣α1A '∣⋯∣α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

• penEHR 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.