Ruby Movement on - PowerPoint PPT Presentation

医療情報分野における標準化の動向 と Ruby 言語による実装 Movement on medical standard and its implementation by Ruby 小林慎治； 愛媛大学医学部第一内科 Shinji KOBAYASHI; Ehime University

Agenda Who am I? Why do I use Ruby?

e-Health care in Japan and My bibliography Era E-Health in Japan My bibliography 1970 Start for research Born in Saga Japan at April Happy Origin 19, 1970 1980 'Receipt computer' Manga, Anime, Computer Hopeful Claiming system for Medical student/ Kyushu development insurance University 1990 Clinical Physicians Order MD license, 1995 Painful / Entry system Resident, Clinical growth hematology/oncology 2000 Electronic medical PhD. research and Explosion record/Electronic health development on OSS in record, full digital 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

Adoption of ORCA 16

Adoption of ORCA （ May 2002 ～ April 2010 ） Working ・・・ 8800 【 specification 】 ・ OSS ＋ Billing software, morethan 1M steps ・ Process 1T JPY( 10B USD) claims/year ・ Only 2 week for adjust new rules/2years Preparing ・・・ 1145 Planning ・・・ 498 17 17

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 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 ISO8601_TIME ISO8601_DATE_TIME rm::support::assumed_library

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

Module = Class - constructor

Class = Module + constructor

ISO8601_Date +initialize I SO8601_Date_Module +year +month +day +as_string

ISO8601_Tim ISO8601_Time_Module e +hour +initialize +minute +second +fractional_second +as_string

ISO8601_Date_Time ISO8601_Date_Module +initialize +year +as_string +month +day +as_string ISO8601_Time_Module mixin +hour +minute +second +fractional_second +as_string a

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

EHR Demographi Integratio Template OM EHR Integratio c n n Composition Archetype prof Security Commo ADL AOM n Data Structures Data Types Support

Effective steps of libraries 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

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 → β 1 A ' ∣⋯ ∣ β m A' A ' →ε∣ α 1 A ' ∣⋯∣ α n A '