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

Transcription

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

2 Agenda Who am I? Why do I use Ruby?

3 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, Hopeful development 'Receipt computer' Claiming system for insurance Manga, Anime, Computer Medical student/ Kyushu University 1990 Painful growth Clinical Physicians Order MD license, 1995 / Entry system Resident, Clinical hematology/oncology 2000 Explosion Electronic medical PhD. research and record/electronic health development on OSS in record, full digital medical field

4 I can do it better!

5 Why do I use Ruby? Cost to change brain mode Lower cost Short time Open source software Object Oriented Programing Language Free to use, financially, politically Next challenge To learn innovative skill of software Experimental, research use

6 Health care environment of Japan Total health insurance system Universal access To provide average level health care to all nations. When, Where, Who, What High cost performance Low cost Longest life span Minimal level maternal/infant mortality

7 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!

8 Health expenditure/gdp

9 'Receipt' claim form Demographics Insurance number Diagnosis Laboratory test/exam Procedure Prescription Many local rules

10 '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

11 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?

12 AYDBTU? VENDOR: ALL YOUR DATA ARE BELONG TO US!?

13 OSS Open license, free distribution Avoid 'lock in' Health data has long life time as Human. Assurance for future availability Drives open standard Share intellectual resources Reference implementation accelerate 'OPEN' standard Cost reduction Not aim, but result.

14 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

15 Grace Murray Hopper

16 Adoption of ORCA 16

17 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

18 Made in Matsue

19 OSS2010, Notre Dame, USA

20 OSS2010, Notre Dame, USA

21 MOSC2010, Kuala Lumpur

22 MOSC2010, Kuala Lumpur

23 Open Source EHR Summit, 2012

24 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

25 2011/12/14 CIMI press release CIMIとは 臨床情報モデリングイニシアティブ(CIMI; Clinical Information Modeling Initiative)は 健康に関 する記録やメッセージ文書として作成され保存さ れる情報が意味論的に相互運用可能なものとな るために 健康情報の内容を表現する共通形式に ついての詳細な仕様を提供するための国際的な 共同研究である 2011年7月から活動 2011/11/29-12/1 London meeting グループとしての基本方針

26 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 ) and the Unified Modeling Language (UML). 3. CIMI is committed to transparency in its work product and process.

27 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 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.

28 Clinical modelingとは 臨床概念の明確化 臨床概念の構造化 集めるべき情報は何か 項目はどれか 血圧 と言う場合に考慮されるべき情報は何か 概念同士の関係を明らかにする オントロジー シソーラス 臨床概念の結合 ユースケースに合わせて必要に応じて概念を組み 合わせる(CDA-RIM, Archetype-Template)

29 The openehr Project

30 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

31 Semantic interoperability of healthcare information

32 Semantic interoperability One record, multiple use Health care provider Government Public health Researcher Clinical use, history presentation Clinical trial Domain authorized concept model Computer processable Domain experts authored

33 Known difficulties

34 Multiple inheritance

35 Single inheritance + mixin (implementation)

36 ISO8601_DATE ISO8601_TIME ISO8601_DATE_TIME rm::support::assumed_library

37 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

38 Module = Class constructor

39 Class = Module + constructor

40 ISO8601_Date +initialize ISO8601_Date_Module +year +month +day +as_string

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

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

43 Circular import

44 A.java import B public class A B.java import A public class B

45 ab.rb class A end class B end

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

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

48 Effective steps of libraries Language Eiffel C# Java Ruby AM RM Total 10,145 8,258 18,403 5,472 17,488 22,960 11,603 3,642 15, ,358 4,303

49 Magic of Duck typing

50 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

51 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

52 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 '

53 Parser benchmark

54 Impact Download More than 2,300(70/version) GitHub 1fork, 8watchers

55 How to install gem install openehr

56 How to use require 'openehr' parser = ADLParser.new(adl_file) archetype = parser.parse

57 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

58 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.