Archetype relational mapping

18 Pages·2015·2.29 MB·English

by  Li Wang

Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88
DOI10.1186/s12911-015-0212-0
RESEARCH ARTICLE Open Access
Archetype relational mapping - a practical
openEHR persistence solution
Li Wang1, Lingtong Min1, Rui Wang2, Xudong Lu1* and Huilong Duan1
Abstract
Background: One ofthe primary obstacles to the widespread adoptionof openEHR methodology is the lack of
practical persistence solutions for future-proofelectronic health record (EHR) systems as described by theopenEHR
specifications.Thispaperpresentsanarchetyperelationalmapping(ARM)persistencesolutionforthearchetype-based
EHRsystemstosupporthealthcaredeliveryintheclinicalenvironment.
Methods:First,thedatarequirementsoftheEHRsystemsareanalysedandorganizedintoarchetype-friendlyconcepts.
The Clinical Knowledge Manager (CKM) is queried for matching archetypes; when necessary, new archetypes are
developed to reflect concepts that are not encompassed by existing archetypes. Next, a template is designed for
each archetype to apply constraints related to the local EHR context. Finally, a set of rules is designed to map the
archetypes to data tables and provide data persistence based on the relational database.
Results: A comparison study was conducted to investigate the differences among the conventional database of
anEHRsystemfromatertiaryClassAhospitalinChina,thegeneratedARMdatabase,andtheNode+Pathdatabase.
Fivedata-retrievingtestsweredesignedbasedonclinicalworkflowtoretrieveexamsandlaboratorytests.Additionally,
twopatient-searchingtestsweredesignedtoidentifypatientswhosatisfycertaincriteria.TheARMdatabaseachieved
betterperformancethantheconventionaldatabaseinthreeofthefivedata-retrievingtests,butwaslessefficientin
the remaining two tests. The time difference of query executions conducted by the ARM database and the
conventional database is less than 130 %. The ARM database was approximately 6–50 times more efficient
than the conventional database in the patient-searching tests, while the Node+Path database requires far
more time than the other two databases to execute both the data-retrieving and the patient-searching tests.
Conclusions: TheARMapproachiscapableofgeneratingrelationaldatabasesusingarchetypesandtemplatesfor
archetype-basedEHRsystems,thussuccessfullyadaptingtochangesindatarequirements.ARMperformanceissimilar
to that of conventionally-designed EHR systems, and can be applied in a practical clinical environment. System
components such as ARM can greatly facilitate the adoption of openEHR architecture within EHR systems.
Keywords: Archetype relational mapping, Archetype, OpenEHR, Relational database, Data persistence
Background information, which is the foundation of the entire EHR
Currently, an electronic health record (EHR) system is architecture. Highly-specialized and complex EHR systems
essential to support clinical practice with information cannot acclimate to the evolution of healthcare data
technologyinhealthcareenvironments.EHRisarepository requirements, which require EHR systems to embrace a
of information regarding the health status of a subject of dynamic, state-of-the-art, rapidly evolving information
careincomputerprocessableform[1].However,healthcare infrastructure [2]. In order to protect EHR systems from
data is generally too complicated, flexible, and changeable changes in the healthcare domain, openEHR [3] has pub-
tocaptureauniversal,comprehensiveandstableschemaof lishedaseriesofspecificationstoguidethedevelopmentof
future-proof EHR systems. Solutions span from informa-
*Correspondence:[email protected] tionmodellingtosystemarchitecture,tomeetthecontinu-
1CollegeofBiomedicalEngineeringandInstrumentScience,Zhejiang allyevolvingneedsofEHRsystems.
University,Room512,ZhouyiqingBuilding,ZhejiangUniversity,38Zheda
Road,Hangzhou,Zhejiang,China
Fulllistofauthorinformationisavailableattheendofthearticle
©2015Wangetal.OpenAccessThisarticleisdistributedunderthetermsoftheCreativeCommonsAttribution4.0
InternationalLicense(http://creativecommons.org/licenses/by/4.0/),whichpermitsunrestricteduse,distribution,and
reproductioninanymedium,providedyougiveappropriatecredittotheoriginalauthor(s)andthesource,providealinkto
theCreativeCommonslicense,andindicateifchangesweremade.TheCreativeCommonsPublicDomainDedicationwaiver
(http://creativecommons.org/publicdomain/zero/1.0/)appliestothedatamadeavailableinthisarticle,unlessotherwisestated.
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page2of18
The concept of openEHR focuses on systems and tools enables domain specialists to participate directly in the
necessary to the computation of complex and constantly production of the artefacts that are interpreted by EHR
evolving health information at a semantic level, according systems, to organize and present healthcare information,
tothefollowingthreeparadigms:separationofinformation andtocontroltheEHRsystemwithoutinterventionfrom
models,domaincontentmodels,andterminologies;separ- thesystemsupplierorre-programming.
ation of responsibilities; and separation of viewpoints [4]. Syntactic and semantic interoperability between differ-
Among these three paradigms, the separation of informa- ent EHR systems is facilitated by the use of archetypes.
tion models, domain content models and terminologies However, agreement between data content and the infor-
promotesasignificantshiftfromthesingle-levelmodelling mationmodelsisnecessaryforrealintegrationandseman-
approach of information system development to a two- tic interoperability [8]. In the single-level modelling
level modelling approach. In the single-level modelling approach, the domain concepts are implicitly contained
approach,domainconceptsthatareprocessedbytheEHR withintheEHR systems.No consensushealthcaredomain
system are hard-coded directly into the application and models exist in healthcare domain models to which EHR
database models. In two-level modelling, the semantics of systems may conform; each system may model different
information and knowledge are separated into a small, aspects and granularity levels of domain concepts, result-
comprehensible,non-volatilereferencemodel(RM),which ing in heterogeneity. In the two-level modelling approach,
is used to build information systems and knowledge the RM ensures that EHR systems can always send infor-
models; archetypes are used as formalisms and structures mation to other systems and receive readable information
toexpressnumerousandvolatiledomainconcepts[5]. in return, thus ensuring data interoperability. Archetypes
TheRMrepresentsthegeneralfeaturesofhealthrecord canbeusedasthecommonknowledgerepositorytoshare
components, their method of organization, and necessary evolving clinical information that can be processed by the
contextualinformationtosatisfyboththeethicalandlegal receiving systems, thus enabling semantic interoperability
requirements of the health record. The RM encompasses [9]. The openEHR system maintains Clinical Knowledge
thestablefeaturesofthehealthrecordbydefiningtheset Manager(CKM)asanofficialarchetyperepositorytosup-
of classes that composes the blocks which in turn consti- portthegovernanceofinternationaldomainknowledge.
tute the record. Archetypes define entire, coherent infor- Specifications of openEHR can be used to create and
mational concepts from the clinical domain [6]. An sustain aflexibleEHRecosystem thatconsistsofmayin-
archetype is a hierarchical combination of components tegrated services, which is too complex to be accurately
from the RM with available restrictions placed on names, processedbysingleapplications[10].Thegeneralarchitec-
possible data types, default values, cardinality, etc. These turalapproachcanbeconsideredasfivelayers:persistence
structures, although sufficiently stable, may be modified (data storage and retrieval), back-end services (including
or replaced by others as clinical practice progresses and EHR,demographics,terminology,archetypes,security,rec-
evolves [7]. Archetypes are deployed at runtime via tem- ord location, etc.), virtual EHR (a coherent set of APIs to
plates that specify particular groups of archetypes to be the various back-end services and an archetype-and-
used for a particular purpose, often corresponding to a template-enabled kernel responsible for creating and pro-
screen form. A template is a specification that creates a cessing archetype-enabled data), application logic (user
tree structure of one or more archetypes, and each con- applications or another service, such as a query engine),
straining instance of various RM types such as compos- andpresentation(thegraphicalinterfaceoftheapplication)
ition, section, entry subtypes, etc. Templates typically [4]. The archetypes share the openEHR innovation of
closely correspond to screen forms, printed reports, and adaptabilitybecausetheyareexternaltothesoftware,while
generally complete information to be captured or sent at keycomponentsofthesoftwarearederivedfromthearche-
theapplicationlevel;theymaythereforebeusedtodefine types [11]. Much current research has been devoted to the
messagecontent[4]. useofarchetypestodrivethepersistence,accessibility,and
By utilizing a two-level modelling approach, EHR sys- presentationofhealthcareinformationsystems[12–16].
temscanbebuiltona stableRMasageneralframework, Most EHR systems in the healthcare field are built
andthususearchetypesasthedomaininformationmodel accordingto the single-level modelling approach, despite
to achieve greater flexibility and stability, particularly in the many advantages of two-level modelling. One of the
situationsinwhichthedomainconceptsare vastinnum- primary reasons is that the persistence layer is inad-
ber, have complex relationships, and evolve continuously. equate to meet the requirements of clinical practice. As
The responsibilities of specialists from the information the foundation of EHR systems, the persistence layer de-
technology domain and the healthcare domain are disen- termines the EHR system architecture, and thus also
gaged:developersfocusonlyonthetechnicalcomponents function as a performance bottleneck. The openEHR
of EHR systems, while specialists develop the structural system promotes a Node+Path persistence solution that
model based on domain concepts and archetypes. This serializes sub-trees of fine-grained data into blobs or
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page3of18
strings based on the object or relational systems [17]. persistence layer to changes in archetypes. One ap-
The data can be serialized according to different granu- proach is to use a general data storage structure that is
larity levels, from top-level information objects to the independent of archetypes, such as Node+Path, which
lowest leaf nodes. Inessence,the Node+Path solution is has been well-investigated. The other approach is to
an entity-attribute-value (EAV) approach, which takes generate a database model to design a persistence layer
advantage of the semantic paths in openEHR data to im- driven by archetypes.
prove the serialized-blob design. The greatest advantages This work presents an archetype relational mapping
of the Node+Path approach are flexibility and simplicity; (ARM) persistence solution based on a relational data-
all data nodes are serialized, and their paths are recorded base that can achieve similar performance to the con-
adjacently in a two-column table of<node path, serialized ventional database in practical clinical environments.
node value>. However, the simplicity of the data storage This work extends the basic ARM method introduced
structure induces complex data retrieval logic, which in a previous proof-of-concept work [24] by providing a
strainstheperformanceofdatainsertionandquery,which more sophisticated mapping approach based on tem-
requires flexibility [18]. Some researchers have reported plates and archetypes in order to map archetypes to re-
similar performances in the processing of entity-centered lational tables. Performance optimization rules and
queries by conventional and EAV models, but that EAV details are then provided. First, the ARM approach is
models were approximately 3–5 times less efficient in the introduced in detail, including archetype modelling,
processing of attribute-centered queries [19]. Evaluations template definition, and mapping rules. Then, the ARM
of persistence solutions using an XML database also indi- is applied to the EHR data requirements of a tertiary
cates that XML databases were considerably slower and hospital in China. A comparison of the generated ARM
required much more space than the relational database database, the conventional database deployed in the
[20]. There has also been similar research into the data hospital, and the openEHR official Node+Path data-
persistence of alternative approaches based on two-level base is conducted. After analysis, the challenges en-
modelling, such as EN13606 [21] or HL7 Version 3 [22]. countered during ARM development are discussed, and
In a proof-of-concept work of EN13606 [7], the data stor- conclusions are provided.
agewas developedby applying Object Relational Mapping
(ORM) [23] to the RM of EN13606; this approach was Methods
investigated by the authors in earlier work [24]. The deep AnunderpinningprincipleofopenEHRistheuseofarche-
inheritance and complicated relationships of the EN13606 types and templates, which represent formal models of
RM induces excessive JOIN operation during data query. domaincontentthatareusedtocontroldatastructureand
Additionally,classesnearthetophierarchybecomeheavily content during creation, modification, and querying [26].
overloaded with data. For example, DATA_VALUE is the The ARM approach employs archetypes and templates to
basic class of all data types, and contains the common generate a persistence model and provide data access
attributesofallinstancesofalldataclasses,butitisunable based on a relational database. The ARM is intended to
tooperateinrealtime[7].IBMClinicalGenomicsmedical fulfillseveralfunctionalities:
researchdevelopedahybriddatamodelbasedontheHL7
Version 3 Reference Information Model (RIM) [25]. The 1) Effectiveadaptationtochangesinarchetypes.
hybrid data model combines elements of both the ORM Archetypesreflectthe changing realities ofEHR,
and EAV approaches, which is well-suited to the sparse and existing archetypes areupdatedovertime.
and flexible data of a medical research data warehouse. Archetype changesresultinseveralchallenges to
However, it demonstrates similar problems to other ORM ARM, suchasthe application ofnewarchetypesto
and EAVapproaches in that it does not improve the per- therelationaldatabase, andthepossibility of
formanceenoughtosupporteffectiveclinicaltransactions. incompatible versionsamongarchetypes,among
The relational database is still of primary importance other potential challenges.
to the data persistence of EHR systems, and its excellent 2) Generationofcustomizedpersistencemodels for
performance has already been well proved in many suc- variousEHRrequirements.Archetypes definewidely
cessful EHR projects and widely-accepted EHR produc- reusable componentsofinformation, and templates
tions. The primary challenge to the application of a encapsulate thelocalusage ofarchetypes and
two-level modelling approach to a relational database is relevantpreferences.Inordertoapply tothelocal
that the domain information model is hard-wired into the EHRcontext,ARMemploystemplatesinorderto
database model; when the domain information model customizethedata persistencemodel.Thereare
changes, the relational database must be redesigned in threesteps toemployARMintheimplementation
order to facilitate the new domain information model. ofthepersistencelayer:archetypemodelling,
Therearetwoapproachestosupporttheadaptationofthe templatedefinition,and databasemapping.
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page4of18
Archetypemodelling Table1Archetypebasicdatatypesandmappingrules
Archetype modelling selects and expands existing arche- Datatype Field Fielddatatype SQLtype
types from the public archetype repository, or defines
CodePhrase codeString String NVARCHAR
new ones in order to meet all data requirements. Arche-
DvBoolean value Boolean INTEGER
type modelling has been well-developed, and widely
applied in previous studies [27–29]. First, all data items DvCodedText definingCode CodePhrase #
must be determined by collecting and analysing the data DvCount magnitude Integer INTEGER
requirements in detail, such as dataset specifications or DvDateTime value String NVARCHAR
database schemas. The data items must then be merged DvEHRURI value URI NVARCHAR
into coherent and meaningful clinical concepts. Then,
DvIdentifier id String NVARCHAR
existing archetypes must be reused as much as possible.
DvMultimedia uri DvURI #
Keywords are used to search the CKM for matching
DvProportion precision Integer INTEGER
archetypes, including concept name and core data items.
Concepts are identified as fully covered by archetypes, DvQuantity magnitude Double FLOAT
partially covered by archetypes, and/or not covered by units String NVARCHAR
archetypes. The archetype will be directly reused if it DvText value String NVARCHAR
fully covers a concept, extended if it partially covers a
DvURI value URI NVARCHAR
concept, and new archetypes are designed for concepts
GenericID value String NVARCHAR
with noexistingarchetypes.
name String NVARCHAR
Link target DvEHRURI #
Templatedefinition
Archetypes describing the general healthcare concepts
are adapted to local EHR data requirements by template adomain contains manyconceptsand dataitems
definition design templates. One corresponding template with similar structures,ageneral concept with a
is designed for each archetype in order to add con- data itemcanbeused tostore thename andall
straints, such as local optionality, archetype chaining, fieldsrelatedtothese concepts.Itisimpossibleto
tightened constraints, default values [26], and ARM con- simultaneouslydefine the vastnumberofconcepts
strains. ARM constrains attempt to achieve better per- includedinEHR systems. Additionally,the
formance by aligning the concept-focused archetype definitionsare difficultto maintain dueto the
model and the data-focused relational model. The ARM continuousdevelopmentofnewconcepts.
constraintsaredesignedasfollows: Archetypescanclearlyrepresentthegeneralconcept
and specificconceptsbyspecialization. Thename
1) Assignidentificationdata item.An identification and fieldsofdataitemsinspecializedarchetypesare
data itemisused touniquely identify instancesof mappedtoa subset offieldsofthe corresponding
each archetype;itcanrepresent anybasicdata type data iteminthegeneralized archetype. Then,the
(Table1)andhasanoccurrenceof0..1or 1..1.Only data storedasageneralized archetype instance can
oneidentificationdataitem canexistforeach bequeried with specializedarchetypes,andvice
archetype. versa,usingthe mappings.
2) Assignquerydataitem.Somedataitemsmayalways
beused asquery conditions,particularlythosewith Databasemapping
identicalcharacteristics totheidentificationdata Database mappinggenerates a relational database schema
item.Thesetypesofdata itemscanbe categorized in order to automatically persist the data represented by
asquerydataitems,andanarchetypemayhave archetype instances into relational databases using arche-
multiplequerydataitemstofacilitatethedataquery. types, templates, and ARM constraints. A set of mapping
CollectiondatastructuressuchasCLUSTER, rulesisdesignedasfollows:
ITEM_TREE,ITEM_LIST,andarchetypeslotscannot
beusedasidentificationdataitemsorquerydata 1) Mapeacharchetypetoatable.Accordingtothe
items.Asbasicunitsofinternalstructuresof archetypesemanticrelationshipspecifiedinopenEHR
archetypes,collectiondatastructuresgrouprelated specifications(Table2)[30],newandoldversionof
dataitems,andcanthusbeviewedasembedded thesamearchetypecanbeorganizedintoasingle
archetypeswiththeirownidentificationdataitems datatable.
andquerydataitems. 2) Mapthebasicdataitemsrepresentedbythearchetype
3) Define mappings betweengeneralized archetypes basicdatatype.Iftheupperboundofthedataitem
and specializedarchetypestofacilitatedata query. If occurrenceis1,thisindicatesasingleoccurrencedata
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page5of18
Table2Semanticalrelationshipsofarchetypes 6) Mapcollectiondata itemsaccordingtocollection
Relationship Modification Compatibility data structure.Iftheupper boundofthe collection
data itemoccurrenceis1,thisindicates a single
Revision Modifydescriptionpart Ensurebackward
compatibility occurrence collection data item,sothedata items
Expandattributes,range Datacreatedby containedinthiscollectiondataitemcanbemapped
ofvaluesets,terminology pre-revisedarchetype intothetableofthecurrentarchetype,andcanbe
iscompatiblewiththe
viewedasflattened.Iftheupperboundofthe
revisedversion
collectiondataitemoccurrenceis*,thisindicatesa
Specialization Strengthentheconstraints Ensurethenewspecialized
multipleoccurrencecollectiondataitemthatis
archetypemustcreate
Redefineandaddnodes datathatconformstothe mappedintoastandalonetablewithoneforeignkey
Therangeofvaluesetsand parent column,referringtotheidentificationdataitemofthe
semanticsofnodesconform
currentarchetype.
tothepreviousarchetype
7) Propagatequerydataitems.An efficientmethodto
Newversion Changemandatoryitem Modificationsare
reducethe recursive leveldeep inthearchetype
tooptional incompatiblewiththe
previousarchetype hierarchytree when querying the leafarchetypeisto
Adjustvaluerangeorcoded
store themost frequently queried dataitemsofthe
termset
ancestorsinthedescendants.Formultiple-occurrence
archetypeslotsandcollectiondataitems,thequery
itemwhichcanbemappedasacommoncolumn.If dataitemsinthecurrentarchetypecanbemapped
theupperboundofthedataitemoccurrenceis*,this identicallytotheidentificationdataitem,intothe
indicatesamultipleoccurrencedataitemwhichis targetarchetypedatatableofthearchetypeslotorthe
mappedintoastandalonetablewithtwocolumns:one standalonedatatableofthecollectiondataitemsas
isaforeignkeycolumnreferringtotheidentification foreignkeycolumns.
dataitemofthecurrentarchetype,andtheotherisa 8) Naming. Naming rulesvaryslightly,because each
commoncolumnmappedfromthedataitem.Table1 relationaldatabaseproduct,suchasMicrosoft SQL
liststhearchetypebasicdatatypesutilizedinARM ServerorOracle,hasunique restrictionsfornaming
andtheircorrespondingmappingrules.Forfieldswith tablesand columns. Thegeneralprinciples areas
non-preliminarytypesineacharchetypebasicdata follows.Thearchetypename isused asthetable
type,thecorrespondingSQLtypeisnotedas“#”and name fortables mapped fromarchetypes.The
themappingsmustbereferencedinTable1. archetypename concatenatedwiththe dataitem
3) Constraintheidentificationdataitem asthekey name isused asthetablename fortables mapped
column.Uniqueandclusteredindexconstraintsare from collectiondata itemsand multiple occurrence
mappedfromtheidentification data item,andadded data items; the versionportionofthearchetype
tothe column. Ifthereisnoidentification data item name shouldberemoved,sinceallversionsofan
inan archetype, adata itemnamed “id”isgenerated archetypeare mapped intothe samedatabasetable.
and usedastheidentificationdataitem toidentify Thepath ofthedata itemconcatenatedwith the
records inthe databasetable; thegenerated“id”is fieldname isused asthe columnnameforacolumn
invisibleand cannotbeaccessedusingthearchetype. mappedfromadataitemfield;the pathofthedata
4) Constrainthequerydata itemasanindexed itemand the columnnameare unique,butthe
column.Thenon-clusteredindex constraints human readabilityofthepath ispoor.One
mappedfromquerydataitemsareaddedtocolumns alternativetoachievebetterreadabilityisto usethe
inordertoacceleratedata query. textualnameprovidedwithinthe archetype
5) Maparchetypeslots.Iftheupperboundofthe ontologysectionofthedata itemratherthanthe
archetypeslot occurrenceis*,thisindicatesthatthe path. However,the uniqueness ofthetextualname
currentarchetypeand thetargetarchetypeexhibita providedwithin thearchetype ontology section of
one-to-manyrelationship,whichismappedasaforeign thedata itemisguaranteed; ifthegeneratednames
keycolumninthetargetarchetypetable,referringto forthetableand columnare solongastoviolate
theidentificationdataitemofthecurrentarchetype.If thenamingrestrictionsoftherelationaldatabase
theupperboundofthearchetypeslotoccurrenceis1, products,they shouldbeshortened inaconsistent
thisindicatesthatthecurrentarchetypeandthetarget mannerinordertoremain unique.
archetypeexhibitaone-to-onerelationship,sothedata
itemsofthetargetarchetypeareembeddedintothe Databasecomparison
tableofthecurrentarchetype,thusembeddingthe A performance comparison ofthe ARM approach and an
targetarchetypeintothecurrentarchetype. EHR system used in real clinical practice in conducted.
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page6of18
ThecomparedEHRsystemhasbeendeployedinatertiary candidate against which to apply the ARM approach and
class A Chinese for three years. Several legacy systems conductthecomparison.
have been integrated into the EHR system, including
HMIS (hospital management information system), LIS Ethics
(laboratory information system), RIS (radiology infor- This study was approved by Review Board of Shanxi
mationsystem),PACS(picturearchivingandcommuni- Dayi Hospital under project 2012AA02A601. A database
cation system), PMS (pharmacy management system), specialist from the hospital’s information technology
and OMS (operation management system). Two informa- department exported and de-identified the necessary
tionsystems,CPOE(ComputerizedPhysicianOrderEntry) data of IV database.
and IV (Integrated Viewer), support the order-centered
clinical workflow for all clinicians from all departments Results
within the hospital. The IV information system allows ARMmapping
clinicians to view the demographic, imaging examination, TheschemaoftheIVdatabasehasbeenanalysedindetail
and laboratorytest data ofa patient scattered in heteroge- andextractedintoconcepts.Fig.1depictstheoverviewof
neous silo systems in one application, rather than being theIVconceptsandtheirrelationships.
forced toaccessdifferent patient datain each correspond- The primary purpose of this investigation is to explore
ing system. The system represents a typical centralized the performance of the ARM approach. Existing matching
data-reporting application in a hospital that presents archetypes in CKM are selected without modification to
patientinformationfromallexaminationdepartmentsand facilitate clear interpretation of comparisons. A total of 17
encompasses most EHR data, thus serving as an ideal archetypesareselectedtoencompasstheIVconcepts.Fig.2
Fig.1IVconceptsoverview.Inallfigures,PKstandsforprimarykey.FKstandsforforeignkey,andindicatesthedataitemwhichcurrentdata
itemrelatesto.SLOTindicatestargetarchetypewhichconformtocurrentdataitem.Solidlineindicatesforeignkeyrelationshipbetween
archetypes.Dashlineindicatescompositionrelationshipthroughslotbetweenarchetypes.IDIstandsforidentificationdataitem.QDIstandsfor
querydataitem.CIstandsforclusteredindexed.NCIstandsfornon-clusteredindexed.Dataitemsinitalictypearenotcoveredbyarchetypes
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page7of18
Fig.2Archetypesoverview.Inallfigures,PKstandsforprimarykey.FKstandsforforeignkey,andindicatesthedataitemwhichcurrentdata
itemrelatesto.SLOTindicatestargetarchetypewhichconformtocurrentdataitem.Solidlineindicatesforeignkeyrelationshipbetween
archetypes.Dashlineindicatescompositionrelationshipthroughslotbetweenarchetypes.IDIstandsforidentificationdataitem.QDIstandsfor
querydataitem.CIstandsforclusteredindexed.NCIstandsfornon-clusteredindexed.Dataitemsinitalictypearenotcoveredbyarchetypes
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page8of18
depicts an overview of the selected archetypes and their (cid:1) openEHR-EHR-CLUSTER.organisation.v1
relationships. (cid:1) openEHR-EHR-CLUSTER.person_name.v1
Atotalof16areexistingarchetypes:
Onearchetype isnewlydesigned:
(cid:1) openEHR-DEMOGRAPHIC-PERSON.person-
patient.v1 (cid:1) openEHR-EHR-OBSERVATION.lab_test-general.v1
(cid:1) openEHR-DEMOGRAPHIC-ITEM_TREE.person
details.v1 Due to the different granularity and reusability between
(cid:1) openEHR-DEMOGRAPHIC-CLUSTER.person_ archetypes and IVconcepts, data items belonging to one
identifier.v1 IV concept are commonly scattered into several arche-
(cid:1) openEHR-DEMOGRAPHIC-PARTY_IDENTITY. types, and vice versa. For example, the Patient concept is
person_name.v1 mapped to four archetypes, represented by slots in Fig. 3.
(cid:1) openEHR-EHR-INSTRUCTION.request-imaging_ The archetype openEHR-EHR-INSTRUCTION.request-
exam.v1 imaging_exam.v1 is mapped to three IV concepts, as
(cid:1) openEHR-EHR-OBSERVATION.imaging_exam.v1 shown in Fig. 4, and the archetype openEHR-EHR-
(cid:1) openEHR-EHR-INSTRUCTION.request-lab_test.v1 OBSERVATION.imaging_exam.v1 is mapped to two IV
(cid:1) openEHR-EHR-OBSERVATION.lab_test.v1 concepts,asshowninFig.5.
(cid:1) openEHR-EHR-OBSERVATION.lab_test- Another common situation is a distinction between
blood_gases.v1 metadata-level modelling versus data-level modelling
(cid:1) openEHR-EHR-OBSERVATION.lab_test-full_blood_ [29]. For example, there are many specific lab test result
count.v1 archetypes, such as blood gases, full blood count, liver
(cid:1) openEHR-EHR-OBSERVATION.lab_test-liver_ function, etc., while the number of lab test results in IV
function.v1 is greater than 200; additionally, more results will be
(cid:1) openEHR-EHR-OBSERVATION.lab_test-thyroid.v1 generated with new technologies and instruments. Since
(cid:1) openEHR-EHR-OBSERVATION.lab_test-urea_and_ the lab test result items all exhibit a similar data structure,
electrolytes.v1 itisconvenienttodefineageneralizedarchetypeopenEHR-
(cid:1) openEHR-EHR-CLUSTER.lab_result_annotation.v1 EHR-OBSERVATION.lab_test-general.v1 specialized from
Fig.3MappingofopenEHR-DEMOGRAPHIC-PERSON.person-patient.v1.Inallfigures,PKstandsforprimarykey.FKstandsforforeignkey,andindicates
thedataitemwhichcurrentdataitemrelatesto.SLOTindicatestargetarchetypewhichconformtocurrentdataitem.Solidlineindicatesforeignkey
relationshipbetweenarchetypes.Dashlineindicatescompositionrelationshipthroughslotbetweenarchetypes.IDIstandsforidentificationdataitem.
QDIstandsforquerydataitem.CIstandsforclusteredindexed.NCIstandsfornon-clusteredindexed.Dataitemsinitalictypearenotcovered
byarchetypes
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page9of18
Fig.4MappingofopenEHR-EHR-INSTRUCTION.request-imaging_exam.v1.Inallfigures,PKstandsforprimarykey.FKstandsforforeignkey,and
indicatesthedataitemwhichcurrentdataitemrelatesto.SLOTindicatestargetarchetypewhichconformtocurrentdataitem.Solidlineindicatesforeign
keyrelationshipbetweenarchetypes.Dashlineindicatescompositionrelationshipthroughslotbetweenarchetypes.IDIstandsforidentificationdataitem.
QDI stands for query data item. CI stands for clustered indexed. NCI stands for non-clustered indexed. Data items in italic type are not
covered by archetypes
archetype openEHR-EHR-OBSERVATION.lab_test.v1 with Finally, the ARM mapping rules are applied to the
threeadditionalmultipleoccurrencedataitems(TestItem, archetypes, templates, and ARM constraints to generate
Result, and Result Unit) according to the Lab Test Data thefinal relationaldatabaseschema,asshown inFig.7.
conceptinIV(Fig.6),alongwiththespecializedarchetypes
torepresenttheseflexiblelabtestresults. Databasepreparation
The subject data item in every archetype is used to To determine whether the performance can meet the
representthepatient himself. requirements of clinical practice, a performance compari-
Table 3 lists the templates and ARM constraints son is conducted between the generated ARM database,
defined accordingtoIVdata requirements. conventional IV database, and the official Node+Path
Mappings between the generalized archetype lab_test- database.
general.v1 and specialized archetypes lab_test-blood_ The schema of the test IV database is shown in Fig. 8.
gases.v1,lab_test-full_blood_count.v1,lab_test-liver_function. Data items not encompassed by archetypes are removed
v1, lab_test-thyroid.v1, and lab_test-urea_and_electrolytes.v1 to maintain comparability of the test IV database. The
are also defined. For example, as shown in Table 4, Node+PathdatabaseschemaisshowninFig.9.Although
name, value, and unit of data item White Cell Count in only one table is required to store all data, one table is
openEHR-EHR-OBSERVATION.lab_test-full_blood_count. assigned to each concept to promote practicality and
v1 are mapped to three data items (Test Item, Result, and greatlyimproveperformance.
Result Unit) in openE HR-EHR-OBSERVATION.lab_test- Adataset isextracted directly from theonlineIV data-
general.v1. base, with dates ranging from 2014-01-01 to 2014-12-31,
Wangetal.BMCMedicalInformaticsandDecisionMaking (2015) 15:88 Page10of18
Fig.5MappingofopenEHR-EHR-OBSERVATION.imaging_exam.v1.Inallfigures,PKstandsforprimarykey.FKstandsforforeignkey,andindicates
thedataitemwhichcurrentdataitemrelatesto.SLOTindicatestargetarchetypewhichconformtocurrentdataitem.Solidlineindicatesforeign
keyrelationshipbetweenarchetypes.Dashlineindicatescompositionrelationshipthroughslotbetweenarchetypes.IDIstandsforidentification
dataitem.QDIstandsforquerydataitem.CIstandsforclusteredindexed.NCIstandsfornon-clusteredindexed.Dataitemsinitalictypearenot
coveredbyarchetypes
and containing 103320 imaging tests, 8573157 images, exam or laboratory test to verify all the results, images,
654213laboratorytests,and4846688laboratorytestresult and reports in detail. The IV updates all information in
items for 29743 patients. All data has been de-identified real time to support clinician responses to patient situa-
by removing all patient names, patient phonetic names, tionswith minimaltime delays.
patientbirthdates,patientdeathdates,anddoctornames. Fivedata-retrievingtestsaredesignedfromthisworkflow
The dataset is imported into three clean instances of the scenario:
test IV database, the ARM database, and the Node+Path
database. The IV database requires 1.60 gigabytes on the Test1:Findallpatientsbelongingtoa single clinician
hard disk, the ARM database requires 2.90 gigabytes, and togenerateadailyworklist.Aclinician seesatleast1
the Node+Path database requires 43.87 gigabytes, which patientperday (Query1.1),an averageof7patients
is far greater than the space required by the other two perday(Query1.2),andamaximum of50 patientsper
databases.Althoughthe Node+Path is muchmoreeffi- day(Query1.3).
cient in storing sparse data, it also includes too many Test2:Findallimagingexams fora singlepatient.A
redundancies to store the path of each archetype data patienthasatleast1imagingexam (Query2.1),an
item. averageof3imagingexams (Query2.2),and a
maximum of26 imagingexams (Query2.3).
Querybenchmark Test3:Findallimagesrelatedtoa singleimaging
TestsareconductedonaDellM4700runningWINDOWS exam. Animagingexam containsatleast1image
8.1 Enterprise 64 bit operating system and Microsoft SQL (Query 3.1),anaverageof363images(Query 3.2),and
Server 2014 Enterprise Edition with an Intel Core i5- amaximum of10664 images(Query3.3).
3340 M processor, 16 gigabytes of memory, and a 5400- Test4:Findalllaboratory testsfora singlepatient.A
RPMharddisk. patienthasatleast1laboratorytest (Query4.1),an
Clinicians use the IV each day to monitor patient averageof23laboratorytests(Query4.2),anda
imaging exams and laboratory tests in order to make maximum of425laboratory tests(Query4.3).
further decisions. The IV presents a patient list for each Test5:Findallresultsina singlelaboratorytest. A
clinician; when a patient is selected, all correlated laboratorytest contains atleast1result (Query 5.1),an
imaging exams and laboratory tests are displayed in two averageof168results(Query5.2),andamaximum of
pages, enabling the clinician to click on each imaging 4477results(Query5.3).