Introduction of BJU-BMR-RG and use case study of Applying openEHR archetypes to CDR implementation

1. Prof. Xudong Lu
Zhejiang University, P.R.China
2016.01.22
Introduction of ZJU-BMI-RG &
Use case study of Applying openEHR
archetypes to CDR Implementation

2. The Biomedical Informatics Research
Group is established in 1996. Through
20 years’ development, it covers many
areas in medical informatics, including
EHR, Data Integration, CDSS, mHealth,
Medical Language Processing, Clinical
Data Mining and Translational
Informatics.
There are totally around 60 staffs
including 2 professors, 4 associate
professors , Ph.D/Master students &
software engineers.
Biomedical Informatics Research
Group in ZJU

3. Use case study: Applying openEHR
archetypes to CDR Implementation

4. Background of the Research
Ø Part of Project of “Medical Data Integration & Merging”, funded by
Chinese National “863” Program, initiated in 2012.
Ø Research Purpose: An methodology of implementing open and
extensible CDR and a case study in a pilot hospital
Shangxi Dayi Hospital with 2600 beds

5. What is CDR ?
Ø Definition of CDR
• A data store that holds and manages clinical data collected
from service encounters at point of service locations (e.g.
hospitals, clinics) (from ISO/TR 20514，2005)
Ø CDR has been widely developed and implemented
internationally.
• 46.7% hospitals in Asia Pacific
• 71.2% hospitals in Middle East
• 67.2% hospitals in Canada
• 94.8% hospitals have implemented CDR in America

6. 0.57% hospitals have implemented CDR in China until 2014
CDR in China
CDR is particularly important for this stage of the
development of medical information in China.
Stage Description 2013
(N=2414)
2014
(N=2622)
Stage 7 Complete electronic medical records system,
regional health information sharing.
0.04% 0
Stage 6 Closed-loop management of the whole process
of medical data, advanced medical decision
support.
0.16% 0.19%
Stage 5 Unified data management, data integration
among department systems.
0.21% 0.38%
Stage 4 Information sharing in hospital, intermediate
medical decision support.
3.89% 5.61%
Stage 3 Data exchange among departments, primary
medical decision support.
13.05% 15.25%
Stage 2 Data exchange within the department. 22.33% 21.78%
Stage 1 Preliminary data collected within the department 11.10% 10.41%
Stage 0 Not formed electronic medical records system 49.21% 46.38%

7. A real-time unified database of patient clinical information
Clinical Data Repository
Patient ServiceClinical Support Research
LIS CPOEPACSHMIS EIS OIS
Interoperability
Integration Engine
CIS
CDR in the hospital

8. 8
The common way of implementing CDR
It’s over-reliance on vendors and time-consuming and
cost-consuming for any extension
Requirements
users
BIG
model
BIG
schema
Concepts & relationships
data
store
communication
information
GUI App
Software
OO devt
RDBMS devt
define
Implemented in
Hard-coded in
developer

9. Problems
Source Items
Requirements 348
Existing CDR* 93
Diabetes-related Data Elements
Cardiac Data Elements
Source Items
Requirements 257
Existing CDR* 101
The data in the CDR are always not enough to fit the requirement
* The existing CDR are the one implemented in EMR-S in one large hospital in China
A case for medical experts to
conduct a long-term follow-
up study on diabetes
A case for CVD department
to introduce a decision
support system
Biotherapy related Data Elements
Source Items
Requirements 103
Existing CDR* 23
A case for medical experts to
conduct clinical research on
biotherapy

10. Clinicians Engineers
Clinical Data Repository
HIS LIS PACS …RIS EIS OIS
Data
Viewer
Data
Analytics
Decision
Support
。。。
Data
Mining
Gap
I want to
query the
count of
patient with
CIK therapy
plan Researchers
I want to find
the relationship
between
diseases and
certain factors
Patients
I want to find
the number
of patients
like me
I want to
integrate my
new system to
CDR
Increasing requirement
cannot be filled
Developed software
cannot be fully used
The Gap between requirement and Reality

11. The Ideal Solution
An Open Extensible Information Platform
Let the people with data requirement retrieve & query
data themselves
I can
configure a
simple form
for my
request
I can get the
necessary
data as input
to analytics
software
I can query
whatever I
needed
I can
transfer the
data to my
own
structure
Clinical Data Repository
HIS LIS PACS …RIS EIS OIS
Clinicians EngineersResearchers Patients

12. OpenEHR methodology ?
The openEHR method has the flexibility and scalability,
and archetypes account for them.

13. The existing artefacts of openEHR community
There are many previous defined archetypes, templates
openEHR Clinical Knowledge Manager (CKM), together
with several implementations around the world

14. Ø Information Modelling: Can archetypes and templates be
used directly in China? What should be extended?
Ø CDR Implementation: How to implement a openEHR-based
system which allow the experts define, retrieve & query data
by themselves?
14
Use Case Study
Applying openEHR archetypes to CDR implementation in China.

15. Archetype modeling
Starting from data schemas of existing EMR, to find whether the
CDR requirements can be modelled using archetypes in CKM
Analyze Existing
database
schema
Merging items
with same
semantics
Referring
exisiting
standards
Abstract Clinical
concepts
Find
Corresponding
archetype in
CKM
Exist
New
archetype
Modification
Cover
concept
completely
Adopt
directly
Yes
No
Yes
No
1
2
3
4
5 6
6
6

16. Analyze data schemas
Analyze the two EMR database schema that is used in more than
200 hospitals in China to collect the basic CDR requirements
Data schema-1 Data schema-2 CDR requirements
PAT_MASTER_INDEX MASTER_PATIENT_INDEX Patient demographics ( 69items)
MEDREC.DIAGNOSIS DIAGNOSIS Diagnosis information (25 items)
MEDREC.PAT_VISIT
OUTPADM.CLINIC_MASTER
INPADM.PATS_IN_HOSPITAL
PATIENT_VISIT
VISIT_IN_HOSPITAL
VISIT_OUT_PATIENT
Admission
Discharge
Transfer (175 items)
ORDADM.ORDERS
OUTPDOCT.OUTP_ORDERS
ORDERS
ORDERS_PERFORM
Order information (92 items)
ORDADM.VITAL_SIGNS_REC VITAL_SIGNS_RECORD Vital signs information ( items)17
EXAM.EXAM_MASTER
EXAM.EXAM_ITEMS
EXAM.EXAM_DATA
EXAM.EXAM_REPORT
EXAM_REQUEST
EXAM_ITEM
EXAM_REPORT
EXAM_DATA
Examination information
(182items)
LAB.LAB_TEST_MASTER
LAB.LAB_TEST_ITEMS
LAB.LAB_RESULT
LAB_TEST_REQUEST
LAB_TEST_DATA
LAB_TEST_MASTER
Lab test information (112items)
OPERATION_SCHEDULE
OPERATION_MASTER
OPERATION_REQUEST
OPERATION_REPORT
Operation information (200 items)
BLDBANK.BLOOD_APPLY
BLDBANK.BLOOD_CAPACITY
Transfusion (36 items)
NURSERECORD_SUMMARY Nursing information (62 items)
CONSULT_MASTER Consult information (39 items)
NEWBORM_REPORT Newborn information (129items)
EMR.EMR_DOCUMENT EMR_DOCUMENT
EMR_DOCUMENT_DETAIL
EMR document information
(88 items)
Total 1226 items

17. 17
Items merging
Merge the items from the data schemas with the same
semantic into 892 CDR data items.
Number of itemsCDR requirements Data schema-1 Data schema-2 CDR items
Patient demographics 26 43 31
Diagnosis information 12 13 15
Admission
Discharge
transfer
119 56 123
Order information 36 56 40
Medication Order None None 57
Prescription None None 42
Therapy None None 21
Diet None None 22
Dispose None None 22
Vital signs information 7 10 12
Examinationinformation 109 73 63
Lab test information 48 64 58
Operation information 79 121 124
Transfusion 36 None 32
Nursing information 62 None 30
Consult information None 39 22
Newborn information None 129 133
EMR document information 28 60 45

18. WS 445-2014 CDR requirements
1) medical record summary patient demographics,
encounters
2) outpatient and emergency medical
record
imaging examination
3) outpatient and emergency
prescription
medication
4) examination and laboratory test
record
imaging examination,
laboratory test
5) general therapy and treatment record medication
6) delivery record of therapy and
treatment
Therapy
7) nursing operation records Nursing
8) nursing valuation and plan none
9) informing information none
10) home page of inpatient medical
record
EMR document
11) home page of inpatient medical
record summary of TCM
EMR document
12) admission record encounters
13) inpatient progress note imaging examination
14) inpatient order medication
15) discharged brief encounters
16) transfer record encounters
17) medical institution information Admission
EMR document
Standardization
Refer two standards by MOH in China in order to get the
standardized representation of data items, totally 553 items.
WS 363-2011 CDR requirements
1) identification patient demographics,
encounters, medication,
imaging examination,
laboratory test
2) demographics and social
economics characteristics
patient demographics
3) health history EMR documents
4) health risk factor EMR documents, operation
5) chief complaint and symptom Diagnosis, EMR documents
6) physical examination Operation
EMR documents
Orders
7) assistant examination imaging examination
8) laboratory examination patient demographics,
laboratory test
9) diagnosis encounters
10) medical assessment encounters
11) medical plan and intervention encounters, medication
12) health expenditure Orders,
13) healthcare organization patient demographics,
encounters, medication,
imaging examination,
laboratory test
14) health personnel Nursing, Therapy
15) drug and material medication
16) health management Nursing, EMR documents
CDR requirements and WS 445-2014 CDR requirements and WS 363-2011

19. Concept acquisition
Guided by Information Model of openEHR, based on the clinical
practice in China, classified 62 clinical concepts

20. 20
Mapping rules
Mapping concepts to archetypes in CKM based on the
mapping rules.
Result of finding Category operation
Exist corresponding
archetype
Covered by archetype
completely
Used directly
Need to modify
description, translation,
extend the value sets.
Revision
Need to specialize the
archetype, add more
constraint.
Specialisaztion
Need to add new items in
the definition section and
keep compatibility.
Extension
Modification that make
the archetype is
incompatible with original
archetype.
New version
No corresponding
archetype
New

21. 21
Archetypes acquisition
73 archetypes have been defined.

22. 22
Results
45 new archetypes, 15 modification , 13 existing
archetypes used directly.
New archetypes(45)Modification and extended(15) No changed(13)

23. Discussion 1
Revision, Specialisation and New version are included
in openEHR specification, while Extension is omitted.
Extension
Revision
Specialisation
New version
MODIFICATION
compatibility
Modify description;
Expand attributes,
range of value sets,
terminology.
Customize an
general purpose
archetype.
Modify definition
part, add new
object nodes that
no need to narrow
than the original.
official

24. 24
Discussion 2
Mismatches exist between metadata-level modelling
and data-level modelling which happen in candidate
archetypes and the CDR requirements.
Data-level
Metadata-level

25. 25
Discussion 3
Problems of the granularity and relationship representation.
Request
Request
item
Result
Report
DICOM
Study
Image
1
N
1 1
1
1
1
1
1
1
N
N
N
N
Request
Request
item
Result
Report
DICOM
Study
Image
1
N
1 1
1
1
1
N
N
N
Request
Request
item
Result
Report
DICOM
Study
Image
1
N
1 1
1
1
1
1
1
1
N
N
N
N
Requirements Archetypes in CKM After modification
2 archetypes 3 archetypes
Image examination
data relationship

26. Ø The methodology of openEHR could be used in China, but
extension to existing archetypes is necessary,
Ø The modelling results so far are still coarse, need to be re-
thinking, discussion with clinicians and align with CKM.
Ø Translation and a convenient editing tool are necessary if we
want clinician to be involved.
Ø The next step would be further diving into broader and deeper
area in the special biomedical domain like cardiovascular,
health management data, and omics data.
What we learned from archetyping?

27. ØInformation Modelling: Can archetypes and templates be
used directly in China? What should be extended?
ØCDR Implementation: How to implement a openEHR-based
system which allow the experts define, retrieve & query data
by themselves?
27
Use Case Study
Applying openEHR archetypes to CDR implementation in China.

28. Archetype-based CDR system – main ideas
Archetype
/Template
Data persistence
Data application
Data manipulation
Model of data storage generated
from archetype
Full featured data manipulation
language on archetype
User interface generated from
archetype/Template
Structured data query and entry
Domain experts
manage the
archetypes

29. Archetype-based flow chart of CDR platform
Start
Archetype
edit
DB Deploy
API Deploy
APP Edit APP Deploy
Database
Application
API
TemplateArchetype
Template
edit
Experts
Based on the established flow, user(s) can acquire database
schema, API and application they want by data modeling, while
the CDR platform generates them automatically with archetype-
driven method.

30. Archetype-driven data storage
Archetype
Model
openEHR
Data
Storage
Medical
Knowledge
Data
Requirement Reference
Model
Archetype
Template
Experts
TRM
Schema
Rules
+
L. Wang, L. Min, R. Wang, X. Lu, and H. Duan, "Archetype
relational mapping-a practical openEHR persistence
solution," BMC medical informatics and decision making, vol.
15, p. 1, 2015.

31. Data persistence
xml database
Basic serialization
XML databaseNode+path
1. Performance slower than conventional RDB
2. Not suite to answer complex query
Take into consideration that almost all the hospitals in China adopt relational database,
the relational database persistence with openEHR approach is necessary.
Hybrid serialization

32. TRM Data persistence
Mapping archetype model into multiple tables, meanwhile,mapping leaf nodes into
field name of relation database table.
(Instruction )
PK
(Observation)
PK
(Evaluation)
PK
(Composition)
PK

33. Template-driven data persistence
Rules for mapping
template to entity
Archetype
OET
TRM
Config
Class
-status_Value
-reservedOrder_Value
-……
Class
-memberName
-memberName
-……
Template Object
Mapping
（TOM）
JPA entity object
Object Relational
Mapping
（ORM）
Template relational Mapping
（TRM） RDB
+
+

34. Performance evaluation
Query IV (ms) ARM (ms) Node+Path (ms)
Query 1.1 80 (+74%) 46 5017
Query 1.2 91 (+54%) 59 5121
Query 1.3 196 (+15%) 170 5358
Query 2.1 221 (+16%) 191 24866
Query 2.2 219 (+17%) 187 25094
Query 2.3 474 (+129%) 207 26158
Query 3.1 242 270 (+12%) 294774
Query 3.2 224 299 (+33%) 297388
Query 3.3 254 411 (+62%) 362950
Query 4.1 198 (+13%) 176 127547
Query 4.2 254 (+32%) 193 128508
Query 4.3 1249 (+57%) 797 129901
Query 5.1 113 186 (+65%) 328181
Query 5.2 125 205 (+64%) 329097
Query 5.3 139 239 (+72%) 388727
Query 6.1 14596 (+5150%) 278 5746
Query 6.2 16340 (+5293%) 303 6029
Query 6.3 16453 (+5140%) 314 6984
Ø A comparison study among
the conventional relational
database, the generated
ARM database and the Node
+ Path database.
Ø Five data-retrieving tests
（Query 1.1- Query 5.3）
Ø Two patient-searching tests
(Query 6.1 – Query 7.2)
Ø The ARM achieve
similar performance as
the conventional
relational databases.
Ø The Node + Path
database requires far
more time than the
other two databases.

35. Archetype-driven Data manipulation
Archetype
Model
Information source
Data
Storage
Medical
Knowledge
Data
Requirement TRM
rules
Archetype
Template
Experts
+
SQL
API
Clause Key word
SELECT SELECT
FROM
WHERE
ORDER BY
INSERT INSERT
UPDATE UPDATE
SET
WHERE
DELET DELET FROM
WHERE
AQLData
Storage
TQL
Query
Engine
Developer

36. Archetype Query Language (AQL)
A complete data manipulate language, including data select,
update, delete, and insert function
Clause Key word Parameter
SELECT SELECT Attribute identify path in archetype
FROM Archetype name
WHERE Attribute identify path in archetype operator (>,
>=, =, <, <=, !=) condition value
ORDER BY Attribute identify path in archetype
INSERT INSERT INTO Archetype instances in the format of dADL
VALUES Attribute identify path in archetype and assigned value
UPDATE UPDATE Archetype name
SET Attribute identify path in archetype operator (=)
condition value
WHERE Attribute identify path in archetype operator (>,
>=, =, <, <=, !=) condition value
DELET DELET Attribute identify path in archetype
FROM Archetype name
WHERE Attribute identify path in archetype operator (>,
>=, =, <, <=, !=) condition value

37. SELECT o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value
FROM OBSERVATIONo [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value >=140 OR
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value>=90
INSERT INTO
OBSERVATIONo [openEHR-EHR-OBSERVATION.blood_pressure.v1]
VALUES o/uid/value =newUID(),
o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value=140,
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value=90
Ø SELECT
Ø INSERT
Archetype Query Language examples
(AQL)
Ø UPDATE UPDATE OBSERVATION o [openEHR-EHR-OBSERVATION.blood_pressure.v1]
SET o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value =140
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value >=90
Ø DELETE DELETE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value
FROM OBSERVATIONo [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value >=140
OR o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value >=90

38. •AQL grammar
•ANTLR grammar analyzer
•Abstract grammar tree
Grammar
analysis
•Archetype
•Variable
•Path
Legality
verification •HQL
•Multiple SQLs
Query
execution
•XML format dADL
•Gzip compression
Result
capsulation
AQL – Execution process

39. Performance comparison
Query
serial
number
Records
count
API(ms) AQL(ms)
1 1 5 6
2 1 9 6
3 1 5 6
4 1 5 7
5 1 5 5
6 1 5 5
7 1 5 5
8 1 6 13
9 1 6 5
10 1 5 4
Average 1 5.6 6.2
Query
serial
number
Records
count
API(ms) AQL(ms)
1 209 10 20
2 1209 21 71
3 2847 41 150
4 56 5 8
5 1221 19 72
6 1971 28 106
7 1337 24 74
8 7 5 5
9 279 15 20
10 532 15 33
Average 966.8 18.3 55.9
Retrieving patient information by patient identifier Retrieving image information by exam identifier
The execution time is similar between AQLquery and API query. On accountof
package for dADL, the AQL average performance is little slower than API.

40. Archetype
Model
Information source
Data
Storage
Medical
Knowledge
Data
Requirement TRM
rules
Archetype
Template
Domain
experts
+ UI
layout
Clinician experts
Drag
Drop
Data
binding
Attributes
edit
Data entry UI
Archetype-driven data application

41. archetype/
template editor
template
archetype/
template database
Application
database
Create/modify
Domain
expert
user
developer
Adjust / organize
archetype
application
Domain expert can use the GUI generator to define GUI whatever he likes
Methods for application development

42. archetype/template editor
template
archetype/
template database
Application
database
create
TRM
expert
AQL
“WYSIWYG”
editor
General software framework
Data application
template
design
archetype
Application development with user-control approach
user
application
In order to achieve user-controlapplication development,this study proposes
archetype-driven approach using application template and general software
framework.

43. UI Controller Data module Database
Web Applications
General framework
GUI
information
Data
binding
Control
information
Application template
<body>
<li style= "p os ition: absolute; height: 32p x; w id th: auto; cursor: pointer ; top : 1 87p x; left: 15px;">
<img ng-class= "U ID ata.label.p icTy p e" class= "CLU STER ">
<span> <b class= "ng-binding">饮酒 史</b> </span>
</li>
<li style= "pos ition : ab solu te; h eig h t: 32px; w idth: auto ; cu rsor: pointer ; top : 187 px; left: 89px;">
<select nam e= "Flag_A lcohol drinking history " id= "/item s[at0 00 5]" template= "openEH R-EH R-
CO MP OS ITI ON .fir st_interv iew.v1" >
<o ption v alue= ""> </o ption >
<o ption v alue= "无">无</option >
<o ption v alue= "有">有</option >
</select>
</li>
<li style= "pos ition : ab solu te; h eig h t: 32px; w idth: auto ; cu rsor: pointer ; top : 216 px; left: 40px;">
<img ng-class= "U ID ata .label.picType" class= "D V_CO DED _TEX T">
<span clas s= "ng-binding">种类 :</span>
<select nam e= "Type _A lcohol drinking history " id= "/item s[at0 00 1]" template= " openEH R-EH R-
CO MP OS ITI ON .fir st_interv iew.v1" style= "w id th:80px;" >
……
</select>
</li>
<li style= "w idth: auto ; p os ition : absolute; height: 32p x; cu rsor: pointer ; top : 216 px; left: 200 px;" >
<img class= "D V_Q UA N TITY ">
<span clas s= "ng-binding">饮酒 量: </sp an>
……
<button class= "b tn b tn-default " type= "b utton " ng-click = "save() ">保存 </button >
</body>
<scr ipt>
fu nction save( scope ){
var aql=”inser t into”;
fo reach (item in scope){
aql=aq l+item .tempate ;
……
} }
</scr ipt>
Data operation function
controls
openEHR template
Application template
Application
template file

44. The development flow
Create
archetype/template
Choose and expand
template
Add controls and
adjust page content
Save pagesLoad application
Choose data items
and generate HML

45. • Archetype/
Template Editor
• Archetype –
relational
mapping
• AQL-based
Data Access
Interfaces
• Archetype
driven UI
configuration
Archetype-based CDR system – architecture

46. CDR Implementation in Chinese Hospital
HIS LIS PACS …RIS EMR CIS
Archetype template
repository
Data access service
Diabetes follow-up Integrated data viewClinical decision support
Research Data Query Quality Data analysis Data mining and analysis
Application based on the CDR
Plan to
implement
Have been
implemented

47. CDR outcome
643665
34664534
1355345
14727482
32676 528600 115371 673619 760687
9236476
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
40000000
Data statistics
Examination request Examination data Lab test request Lab test data
Operation request Diagnosis Health examination Patient
Encounter Order
Ø 89 archetypes,85 tables and 142 APIs.
Ø Data volume (2012.8—2015.12)
• Medical data 120G
• 673619 patients and 760687 encounters

48. Integrated viewer application based on CDR
Integrated viewer application allows clinicians to view the demographic,
imaging examination,laboratory test and orders based on the CDR platform
and services.

49. Diabetes Follow-up data management application
based on archetype
Ø Domain experts drag and
drop the attributes from
the templates to control
the UI.
Ø The control type
automatic generated
based on the archetype
template, ARM and
Reference model.
Ø Manipulating the Data
binding with archetype
model according the
clinical practice.
Diabetes Follow-up data managementapplication can be build by the domain
experts with the archetype-driven method,including data persistence, data
access and UI.

50. Ø openEHR is a promising methodology to provide a open
and highly extensible solution for building CDR
Ø Although more applications is necessary for verifying the
feasibility and performance of Archetype/Template driven
approach, the use case show its feasibility.
Ø To fully use the advantages of openEHR still need the
support from the communities.
What we learned from implementation?

51. Plans of promoting openEHR in China

52. Ø Not too many groups are working with openEHR, while HL7
things are very popular.
Ø The information interoperability is not good among different
institutions and even among different systems in one
institution. HL7 don’t solve the problem as well as they
promised to.
Ø BIG DATA and data sharing become more and more
important, it’s just the time for promoting openEHR! But the
engagement of clinicians and vendors is still a problem
The situation of openEHR in China now

53. Ø Open Speech to introduce openEHR concepts in forum of CMEF’16
in April 17-20
Ø Initiate the openEHR Chapter under China Association of Medical
Devices Industry Medical Software?
Planned activities to promote openEHR
--make more people know openEHR

54. Ø Use openEHR methodology in national projects
Ø Enhancing the CDR use case in Shangxi Dayi Hospital.
Ø Possible linkage to Regional Healthcare Data Center in Ningxia
Province
Ø Working closely with openEHR community and learn
from successful localization samples like Japan.
Planned activities to promote openEHR
--create successful stories of using openEHR

55. Thanks for attention!
Welcome to MEDINFO 2017 –
XIAMEN,CHINA
August 21 -25, 2017