SheffieldHallamUniversity SchoolofComputingandManagementSciences

DesignPrinciplesforExtensibility:
DetailedTechnicalAnalysisofExtensibilityof anOpenSourceMedicalRecordSystem

UpulIndikaGodage
January2011 Adissertationsubmittedinpartialfulfillmentoftherequirementsof theSheffieldHallamUniversityforthedegreeofMasterofSciencein EnterpriseApplicationDevelopment

Abstract
Inenterpriseapplicationdevelopmentadesignisimplementedtomeettheuserrequirements.When theuserrequirementschangeorwhenotheruserswantnewfeaturesthedevelopershavetoredesign build,testandshipanewrelease.Thisisthetypicalsoftwaredevelopmentlifecycle.Anextensible systemcanchangethat. Extensibilityistheabilityofsoftwareforfuturegrowth.Extensibilitydoesnotmeanbloatedsoftware.It meansthesoftwarearchitectureisdesignedtoincorporatemechanismsforextendingthesystemwith newcapabilitieswithoutmodifyingthebasicsystemtosatisfynewrequirements. OpenMRSisonesuchextensiblesystem.Itisacommunitydevelopedopensourcemedicalrecord system.IthasbeenusedtorecordpatientdataintheHIVtreatmentprogramsinKenya,Rwanda, Tanzania,multidrugresistanttuberculosisstudiesinPeruaswellasforpediatricclinicsinIndianaand tuberculosistreatmentclinicsinLosAngeles,USA.ThepowerofOpenMRScomesfromtheextensible datamodelandthepluggablemodulearchitecture. ThisresearchprojectwillinvestigateandanalyzetheOpenMRSarchitectureandfindoutthekeydesign principlesbehindtheextensibledatamodelandthemodulearchitectureofOpenMRS.Thisresearch withtheempiricalevidencefromtheextensiondevelopercommunityandanalysisofthesystemandthe sourcecodearguesthatfollowingthesetechnicalandhumanfactorprinciplestheOpenMRSsystemhas effectivelyachievedanextensibledesign.Thisknowledgewillhelptounderstandandapplyeffective designprinciplesonhowtobuildextensiblesoftwaretosupportnewrequirementswithoutconstantly changingthesystems.

Contents
Abstract..........................................................................................................................................................i Contents........................................................................................................................................................ii ListofFigures................................................................................................................................................v ListofTables................................................................................................................................................vi Acknowledgements ....................................................................................................................................vii . Glossary......................................................................................................................................................viii Introduction..................................................................................................................................................1 ExtensibilityinContext.............................................................................................................................1 AimoftheResearch..................................................................................................................................2 ExtraProjectWork....................................................................................................................................3 RoadMap..................................................................................................................................................3 ResearchMethodology.................................................................................................................................4 Approach...................................................................................................................................................4 InterviewsandQuestionnaires.................................................................................................................7 AnalyzingtheSourceCode.......................................................................................................................8 GatheringDatafromthePublicModuleRepository................................................................................8 ConceptualModelforEvaluation.............................................................................................................9 LimitationsoftheResearch....................................................................................................................12 LiteratureReviewandInitialAnalysis.........................................................................................................13 Extensibility.............................................................................................................................................13 MonolithicSystemsvs.ModularSystems..............................................................................................13 MedicalRecordSystems.........................................................................................................................14 OverviewofOpenMRS............................................................................................................................15 OpenMRSArchitecture...........................................................................................................................16 ModuleArchitecture...............................................................................................................................19 ii

ExtensionMechanism.............................................................................................................................20 StylesforExtensibility.............................................................................................................................21 ModuleLimitations.................................................................................................................................22 ExtensibilityinOtherPlatforms..............................................................................................................24 OtherMedicalRecordSystems...............................................................................................................25 DesignPrinciplesOverview.........................................................................................................................27 OpenClosePrinciple...............................................................................................................................27 Liskov'sSubstitutionPrinciple ................................................................................................................27 . InterfaceSegregationPrinciple...............................................................................................................27 DependencyInversion............................................................................................................................28 DerivedPrinciples...................................................................................................................................28 FurtherAnalysisofDesignPrinciples..........................................................................................................30 AspectOrientedDesign..........................................................................................................................30 SingleResponsibilityPrinciple ................................................................................................................31 . Generalization.........................................................................................................................................33 KeyValueDataModel.............................................................................................................................36 LeverageandReuseExistingTools.........................................................................................................39 UserCenteredDesignandPublicDesignProcess..................................................................................42 InternalizationfromInception................................................................................................................43 PrincipleofUsingMetaphor...................................................................................................................44 UseofStandards.....................................................................................................................................46 SecurityfromInception..........................................................................................................................47 ConclusionandFutureWork......................................................................................................................49 Bibliography................................................................................................................................................52 AppendixAProjectPlan...........................................................................................................................57 AppendixBProjectProposal....................................................................................................................58 iii

Introduction........................................................................................................................................58 LiteratureSurvey.................................................................................................................................60 ResearchMethodology.......................................................................................................................62 GatheringandAnalyzingData............................................................................................................63 Ethics...................................................................................................................................................63 OutcomesoftheResearch..................................................................................................................64 Bibliography........................................................................................................................................64 AppendixCOpenMRSSystemArtifacts...................................................................................................70 ModuleFolderStructure ........................................................................................................................70 . SampleModuleConfigurationFile.........................................................................................................71 SampleModuleApplicationContextConfiguration...............................................................................72 AppendixDSampleQuestionnaire..........................................................................................................73 AppendixEInterviewSchedule................................................................................................................75 AppendixFQuestionnaireandInterviewResults....................................................................................76

iv

ListofFigures
Figure1Theresearchwheel.........................................................................................................................6 Figure2Theconceptualmodeltoevaluateextensibility.............................................................................9 Figure3OpenMRStoplevelarchitecture...................................................................................................17 Figure4Privilegerolemodel......................................................................................................................23 Figure5Layeredarchitecture.....................................................................................................................32 Figure6Personattributemodel.................................................................................................................34 Figure7Presentingpatientdatainagenericcolumnsystem....................................................................37 Figure8Extendingthepersistencelayerandserviceslayer......................................................................40 Figure9Modulesreferencingcoredomainobjects...................................................................................41 Figure10OpenMRScustomservletdirectingrequeststomoduleservlets..............................................45 Figure11Extendingasaportalcontainer..................................................................................................46

ListofTables
Table1Statictablestructuretorecordpatientdata.................................................................................36 Table2Genericcolumnstorecordpatientdata........................................................................................36 Table3Givinglabelsintheuserinterfacelevel.........................................................................................37 Table4Keyvaluedatamodel.....................................................................................................................38

vi

Acknowledgements
Iwouldliketothankallthepeoplethathadhelpedmethroughmymasters.Specialthankstomy supervisors,ProfessorJawedSiddiqiandProfessorChristopherBates.Thankyouverymuchforyour patienceandguidance.AlsoIwouldliketothankallthelecturersandthestaff. IwouldliketothankBenWolfe,ProjectManagerofRegenstriefInstitute,forwelcomingmeinto OpenMRSandhelpingmeoutinalloccasions.WithoutyourhelpIwouldhaveachievednothing.Thank youverymuch. IthanktheOpenMRScommunityincludingdevelopers,implementersandusersworldwidewhohave builtagreatproducthelpingthehumanityfightagainstdeceasesandanactiveandfriendlyopensource communityaroundit. Lastbutnotleast,Iwouldliketoexpressmygratitudetomyparentsandallmyfriendsforthesupport andencouragement.

vii

Glossary
AMPATH AMRS AOP API CDC CJK CSV DAO EMR ERP HL7 IDE MMRS OCC PEPFAR SaaS UI WHO AcademicModelforthePreventionandTreatmentofHIV/AIDS AMPATHMedicalRecordSystem AspectOrientedProgramming ApplicationProgrammingInterface CenterforDiseaseControl ChineseJapaneseKorean CommaseparatedValues DataAccessObject ElectronicMedicalRecord EnterpriseResourcePlanning HealthLevelSeven IntegratedDevelopmentEnvironment MOSORIOTMedicalRecordSystem OpenMRSConceptCooperative President'sEmergencyPlanforAIDSRelief SoftwareasaService UserInterface WorldHealthOrganization

viii

Introduction
ExtensibilityinContext
Intypicalenterpriseapplicationdevelopmentprocessestheanalystsandtheusersdiscussandagree upononasetofrequirements.Thenthedevelopersdesignasystemtofulfillthoserequirements.Finally theybuild,testandreleasethesoftwaretotheusers.Whentheuserrequirementschangeorwhen anotherclientwantsasimilarsolutionwithsomecustomfeaturesthedevelopershavetoredesign, build,testandshipanewrelease.Thisisthetypicalsoftwaredevelopmentlifecycle. Usershavedifferentrequirementseveniftheyareinthesameindustry.Forexampleclientswhoare lookingforatravelmanagementsystemwillrequireconnectingtovarioushotelreservationsystems, train,flight,taxireservationsystems.Theclientswhoarelookingforabillingsystemwillneedto connecttodifferentpaymentgatewaysandtheywillhavedifferenttaxcalculationrequirements.The aboveextensibilityrequirementsarerelativelypredictableandstraightforward.Movingfurtherthe futurerequirementscanbemorecomplexandunpredictablesuchascapturingandstoringadditional dataandcreatingreportswiththeaggregatedata.Itisimpossibleforthedeveloperstoguessallthe futureneedsoftheusercommunityortoforeseetheenvironmentsinwhichthesoftwarewillbeused in. Enterprisesoftwaredeveloperstrytodesignanddevelopsoftwaretargetedforthemajorityofclientsin theverticalmarketssuchasaccounting,logisticsmanagement,inventorycontrolsystemsetc.Whena clientrequestsanewfeaturethedevelopersshipanewreleasebuildinguptheportfoliooffeaturesof theproduct.Typicallythesesoftwaresystemsincorporatemethodsforusercustomizationsinalimited manner.Mostofthetimeusershavetoadjusttheirexistingprocessestostreamlinewiththesoftware. Oneapproachusedbythecontemporaryinformationsystemsdesignersaccordingtotheauthors personalexperienceandthepeopleinterviewed,isincorporatingallthefeaturesintothesystemand providingafeatureenablingmechanismatbuildtimeoratruntimeaccordingtothecustomer.The advantageofthisapproachisthatwhenthefeaturesetislimitedandisstraightforwardtoimplement thismethodistheobviousmethodtodesignfromthedeveloperspointofview.Fromtheviewsofthe intervieweesitwascametonoticethatmanysystemsusethisapproachbecausethesystemsare developedorganicallyinsteadofusingasystematicapproachtodesign.

Itwassaidthatoneofthemainreasonsforthisapproachwastheurgencyofdeliveringthefeatures insteadoftakingtimetodevelopthesystemusinggooddesignprinciples.Butmostintervieweesagree thatalthoughthisapproachgivesquickresultsintheshortterm,theywillhavetoundothesequickfixes whentherequirementsbecomemorecomplexandmorediverse.Wheninvestigatingthesourceofthis particularmedicalrecordsystemitwasevidentthiskindofquickfixesexist.Anditwasalsoevidentthat laterdevelopmentworkarerelatedtoremovingthesequickfixeswithpermanentsolutionsthatare extendableandthedeveloperstrytogeneralizethesefixessothattheycanbeusablebyamoregeneric userbasetosupportfuturerequirements. Theabilitytohandleunforeseenchangesandfutureneedseasilyisanimportantqualityofsoftware especiallyforsoftwarewhichisdevelopedforverticalmarkets.Havingasinglewelltestedsystemto handlemanyclientsrequirementsreducesthecostandincreasestheprofitabilityofthesoftware developmentbusinessexponentially.Thatiswhyextensiblesoftwareisimportant. Extensibilityinsoftwaremeanstheabilitytoaddnewfunctionalitywithminimaleffort.Anextensible systemcansupportfuturerequirementswithoutchangingthebasesystem.Extensibilitydoesnotmean bloatedsoftwarewhichincorporatesalltheknownuserrequirementsinasinglebundlesothateach userwilluseasubsetofallthefeatures.Extensibilitymeansthesoftwarearchitectureisdesignedto includemechanismsforextendingthesystemwithnewcapabilitieswithoutmakingchangestothebase systemtosatisfynewrequirementsorworkinnewenvironments. Designinganextensiblearchitectureisabitofaguessinggame.Thedesignersareanticipatingthefuture usagescenariosandrequirementsthatdonotexisttodayandaredesigningasystemarchitecturethat cansupportthosechanges.

AimoftheResearch
Theaimofthestudyistoinvestigateandformulatethekeydesignprinciplesbehindtheextensibilityof OpenMRSarchitecture.Toachievethatobjectivethisresearchwillgathertheempiricalevidencefrom theextensiondevelopercommunityandanalyzethesystemandthesourcecodetoarguewith observationsthatfollowingthesetechnicalandhumanfactorprinciplestheOpenMRShaseffectively achievedanextensibledesign. Thisknowledgewillhelptounderstandtheeffectivedesignprinciplesneededtobuildextensible enterpriseapplicationstosupportnewrequirementswithoutconstantlychangingthesoftware

systems.Oneobjectiveincomingupwiththesedesignprincipleswastomakethemspecificand concreteenoughsothattheycanbeappliedinrealworldenterpriseapplicationdevelopmentscenarios effectivelyasbestpracticesbutgenericenoughsothattheycanbeappliedinanyindustrynotspecific tothemedicalrecordsystems. Byfollowingthesedistilledprinciplestheauthorhopesthatthesoftwarearchitectscancomeupwith leanandextensiblesystemsthatwouldwithstandthefuturerequirementsintroducingminimalcoderot orsoftwareentropywithoutfeaturebloatorwithoutmajorsystemreengineeringeffortslaterinthe lifecycle. Becausethecontentintheinitialprojectproposalwastoobroadandextensive,theresearchproject wasnarroweddownintoidentifyingthespecifictechnicalandhumanfactordesignprinciplesfor extensibilityintheOpenMRSarchitecture.

ExtraProjectWork
DuringmystudyperiodIhavecontributedtotheOpenMRSprojectthroughtheGoogleSummerofCode programin2008andasaninternintheOpenMRSInternshipProgram(OIP)in2009.SincethenIhave beeninvolvedintheOpenMRSprojectasavoluntarycontributor.

RoadMap
Firstthedissertationwilldescribetheresearchprocessthatwasfollowed,howthedataweregathered andtheconceptualmodelusedtoanalyzeandextractthekeydesignprinciples.Thenitwillgivean overviewoftheOpenMRSandthemodulearchitecturetoaconsiderableextentastheextensibility principlesresideinthemodulearchitectureandthekeyvaluedatamodel.Thenitwillevaluateand discusstheidentifieddesignprinciplesonebyonethatarethebasisforextensibilityinthesystemin detailusingevidencefromthesystemandtheinterviewfindings.Thedissertationendswith summarizingthedistilleddesignprinciplesandfurtherwork.

ResearchMethodology
Thischapterwilldiscusstheresearchmethodologyselection,howthedataweregatheredandthe evaluationcriteriamodelthatwasusedtoanalyzethedata.

Approach
Itissaidthattheresearchprocessislikeanhourglass.Itstartsfromthegeneralquestions.Thenthe processnarrowsdowntofocusonspecificaspectsoftheresearchproblem.Finallytheconclusion generalizestheresultsinrelationtotherealworld.Thisresearchwilldiscussabouttheextensible softwarearchitecture,formulatesomekeydesignprinciplesusedintheOpenMRSarchitectureandthen describetheevidenceacquiredfromtheresearchpertainingtothesedesignprinciplesintheOpenMRS softwarearchitecture. Beforestartingtheresearch,theresearchmethodswereinvestigatedtofindasuitablemethodology.A researchmethodologydefineshowtheresearchshouldbecarriedout.Therearemanymethods practicedbytheresearchcommunityincludingexperimentalresearch,quasiexperiments,action researchandethnography(Gill&Johnson,2002).Thechosenmethoddependsonthenatureofthe researchproject. Qualitativeresearchandquantitativeresearcharetwomainschoolsofthoughtintotheresearch process.Inthestudyofmathematics,chemistryorphysicsexperimentsarequiteeasytocomprehend bydefiningtheindependentanddependentvariables,operationalizingthefuzzyconceptsandcoming upwithscientificmeasurements.Quantitativeresearchconcernsaboutsystematicscientific investigationofquantitativepropertiesandtheirrelationships.Quantitativeapproachcouldfocuson theuseoflargescalesurvey,usingmethodssuchasquestionnairesorstructuredinterviewsasinthe marketingfield. Ontheotherhandqualitativeresearchfocusesonexperiences,attitudes,observations,behaviors, motivations,aspirations,valuesystems,concerns,cultureorlifestyle.Qualitativeresearchapproachis lessconcretethanpurenumericaldata.Itdoesnotrelyonstatisticsandnumbers.Itwouldyield descriptiveresultsthroughinterviewsandobservations. Qualitativeimpliesthatthedataareintheformofwordsasopposedtonumbers.Thereismore emphasisondescriptionanddiscoveryandlessemphasisonhypothesistestingandverification,asthe

qualitativeresearcherseeksapsychologicallyrich,indepthunderstandingoftheindividual(Rudestam& Newton,2001). FurtherRudestam&Newton,2001statesthatqualitativeresearchmethodssharethreefundamental assumptions. 1. Aholisticviewthewholeisdifferentthanthesumofitsparts. 2. Inductiveapproachitbeginswithspecificobservationsandmovestowardsthedevelopmentof generalpatternsthatemergefromthecasesunderstudy. 3. Naturalisticinquiryitisintendedtounderstandphenomenaintheirnaturallyoccurringstates. Inthischosentopictheaimwastofindoutthekeyprinciplesbehindtheextensibilityofsoftware architectureinOpenMRS.Lookingattheabovethreepointsitismuchmoresuitabletoapproachthe subjectasaqualitativeresearchastheoutcomeisfocusedonanalyzingthesystemandextractingthe keydesigndecisionsbehindtheextensibilityofthesoftwaresystem. Anotherapproachtoviewtheresearchmethodologyiswhethertheapproachisinductiveasmentioned aboveorwhethertheapproachisdeductive(Rudestam&Newton,2001).Inductiveresearchisbasedon inductivethoughtorreasoningwhichtransformsspecificobservationsintoageneraltheory.The researcherobservespatternsandconductssurveysorexperimentstoverifythevalidityoftheconcepts andthusreachaconclusion.Deductiveresearchisbasedondeductivethoughtwhichtransformsinto specifichypothesissuitablefortesting.Theresearchermayhaveaparticularhunch,aphenomenonand trytocollectdatatoproveitisrightorwrong.Indeductiveresearchfirstthetheoryisputforthinthe formofahypothesisandthenselectsamethodbywhichtotestit.Ifthedatasupportsthehypothesis thetheoryiscorrect.Thisprojectisapproachedinaninductivestylegatheringdataandcomingupwith thethemesrelatedtoextensibility.Thethemesareformedandmoldedduringtheresearchitselfinto designprinciples.Inthiscasedeductiveresearchisnotsuitablebecauseitisnotpossibletoknowthe designprinciplesfromtheoutsetbuttheyemergeasaresultoftheresearchitself. Theresearchcanbevisualizedasaresearchwheel(Rudestam&Newton,2001).Thatmeansthe researchprocessisarecursivecyclicprocessandisnotlinear.Thefollowingdiagramillustratesthe researchwheel.

Conceptualframework

Researchquestion Proposition Dataanalysis

Empiricalobservation Datacollection
Figure1Theresearchwheel

Inthiscasetheresearchquestioniswhatarethetechnicalandhumanfactordesignprinciplesthatcan beenseenintheOpenMRSarchitectureforthebasisofextensibility.Theresearchcyclegoesthrough twopaths.Thatisdatacollectionfollowedbydataanalysisandtheobservationsfollowedby proposition.Thisresearchwascarriedoutinaniterativemannerintwoways.Thatisanalyzingthe systemarchitecture,thesourcecodeandtheavailabledocumentationandaskingthequestionhowdid theydesignthearchitectureextensibletosupporttheserequirements,andsecondlybyopendiscussions withthedeveloperswhowereavailabletorefinetheseanswersintodesignprinciplesfurther.Asthe timeprogressesthethemesformulatedbytheresearcharegenerated,modifiedandsometimes discardeduntilasetofcoreprincipleswerederived. IhavebeenworkingandcontributingtotheOpenMRSprojectduringthisperiodwhilestudyingand analyzingthesystem.Themajorityofthetimewasspentonanalyzingandevaluatingthesourcecode andanalyzinghowtheOpenMRSdevelopershavedesignedthebasesystemwiththeextensibilityin mind.Themainobjectiveoftheinvestigationwastofindoutanditemizethemostsalientdesign principlesbehindtheextensibilityofthesystem. AccordingtoRudestam&Newton,2001therearetwokindsofskillsnecessaryfortheresearchprocess. Thatis, 6

Knowledgebydescriptionlearninginapassivemodesuchasreadingabook. Knowledgebyacquaintancelearningbydoingsuchasdrivingacar.

WhiledoingthisresearchinadditiontoreadingandanalyzingtheOpenMRSsource,Ihaveworkedin developingextensionsforOpenMRSaswellasaddingnewfeaturesandenhancementstothecore OpenMRSsystem. Oneimportantfactwasthatthetasksthatwereperformedwerenotconstrictedpurelyforeducational oracademicpurposesuchasdevelopingextensionsasprototypesbutwereapplicableintrueusecases appliedinpracticalsituationsinrealscenarios.Sothisgavetheresearchapracticalperspectiveintothe workingsofthearchitecture.ThedevelopmentcontributionImadeduringtheprojectisbeingused aroundtheworldinimplementationsitesinAfricanandSouthAmericancountriesinfightingepidemics anddeceases. SotheresearchwascarriedoutbyiterativelyevaluatingtheOpenMRSarchitecture,analyzingthe sourcecode,gatheringdatafromtheexistingextensionsandanalyzingthemagainsttheconceptual modelpresentedlater,andcarryingoutinterviewsandopenendedquestionnaireswiththeselected developers.Thefollowingsectionswilldescribethetasksinmoredetail.

InterviewsandQuestionnaires
OpenMRScommunityarescatteredallaroundtheworld.Mainlytherearethreekindsofmembersin thecommunity.Thesearethedevelopers,theimplementersandtheusers.Thedevelopersdevelopand testthesoftware.TheimplementersarethepeoplewhoinstallandadministerOpenMRSsoftwareata siteusuallyatahospitaloraclinic.Theusersarethepeoplewhousethesystemdaytodayintheir jobs.Thesamepersoncanplayallthreeroles.Typicallymanydevelopersplaytheroleofthe implementer.Alsothedeveloperscanberoughlydividedintothefollowingcategories.Coredevelopers areresponsiblefordevelopingandmaintainingthebasesystem.Moduledevelopersownspecific moduleswhichareextensionsorplugins.Alsothereisacommunityofcontributorswhoprovide patchesandsupporttotheusercommunityvoluntarily. Ihadopendiscussionswithsomeofthecoredevelopersonwheretolookforinthesourcecodetoget somepointersinthedesignforextensibility.ToinvestigatefurtherIselectedaroundthirtypeople encompassingthedevelopers,theimplementersandtheusersoftheOpenMRScommunity.About2/3 ofthesamplewerethedevelopersfromwhich1/3werecoredevelopers.Twouserswhowereclosely

involvedinthedaytodaydiscussionwerealsoselectedforcompletion.Theywereallaskedanopen endedquestionnairelistedintheappendix.Thequestionswereastartingpointtoacquiretheir experiencesextendingOpenMRScoresystemandwhatstrongpointstheysawinOpenMRSwhen customizingandextendingthesystemwithmodules,whatweretheweaknessesandshortcomingsthey found.TheresponseswerelowerthanIinitiallyexpected.Theresponseswereanalyzedandaggregated. Therespondentswerefollowedupforfurtherdiscussionstounderstandtheextensibilitypointsinthe OpenMRSandgetclarifications. TheappendixesQuestionnaire,InterviewScheduleandInterviewResultslistthesamplesanda compilationoftheextensibilityfeaturesandlimitationsaccordingtothesurveyedparticipants.Note thattheresultsareusedinexplainingthedesignprinciplesintheFurtherAnalysisofDesignPrinciples chapter.

AnalyzingtheSourceCode
OpenMRSisanopensourcesoftwareprojectlicensedundertheOpenMRSpubliclicensewhichis derivedfromtheMozillapubliclicense.Sothecompletesourcecodeisavailableonpublicservers accessibletoeveryone(OpenMRSSourceCode,2010). Thesourcecodeiswellmaintainedandeasytocomprehend.Thesourcecoderepositorycontainsthe basesourcecodeandaseparatedirectorystructureformodulesorextensions.Therearenearly200 modulesavailablewiththesourcecodeatthemomentcoveringfeaturesfromaddingdynamicdatabase backuptasks,advancedreportgenerationtoolstoaddingagraphicalHTMLformdesignertothebase systemandaddinguserspecificfeatures.Themodulerepositorycontainsthemodulesreleases (OpenMRSModuleRepository,2010). AlsothereisawikiwithOpenMRSdocumentationondifferentsubjects.Theywerehelpfulto understandhowtheOpenMRSworked.Buttherewerenodesigndocumentsdescribingtheinitialplans anddiscussions.Thesystemhasmostlyevolvedovertimeorganically.Theproductdocumentationisnot comprehensiveanddoesnotgetupdatedoften(OpenMRSDocumentation,2010).

GatheringDatafromthePublicModuleRepository
ModulerepositoryisthecentraldistributionpointofOpenMRSextensionsthathavebeenwrittenby variousdevelopersovertheyears.Whengatheringdataabouthowthedevelopershaveextended OpenMRS,thiswasthemaindatagatheringpointfortheresearch.Byanalyzingthemodulesandthe 8

sourcecodeitwaspossibletoevaluatehowtheOpenMRSsystemhasbeenextendedfordifferent purposesbydifferentpeople. Ontheotherhandthemodulerepositoryhostsonlythemodulesthatarereleasedundertheopen sourcelicense.Theownerhastoagreetothelicensebeforeuploadingamodule.Sothereisthe possibilitythatsomepartycouldhavewrittenamoduletofulfilltheirownneedsthathasnotbeen releasedtothepublic.ButaccordingtotheOpenMRSdeveloperstherehasnotbeenanyrecorded instanceofsuchaprivatelyheldmoduledevelopmentorusebecausemostoftheprojectswhichare usingOpenMRSarerunbypubliclyfundedprogramsandvolunteers.Infactmostoftheinterviewees weretheauthorsofthesemodules.

ConceptualModelforEvaluation
Whileanalyzingthemodulesaframeworkmodelwasneededtounderstandwhatthepurposeofthe extensionandhowitinteractswiththecorearchitecturetoactasaseamlesssingleunit.Thefollowing diagramillustratestheevaluationmodelthatwasusedtoanalyzetheextensibilitypointsinthe OpenMRSsystem.

UserInterface

ExternalEvents/Input

BusinessLogic/ Services

PublishEvents/ Output

DataModel

Figure2Theconceptualmodeltoevaluateextensibility

Thisconceptualmodeldescribesthekeyareaswheredevelopersfocusonwhenextendingthebase system.TheOpenMRScoresystemcanbethoughtofastheinfrastructureandtheskeleton.The extensionsplugsintothismodeltoprovideorenhancetheservices.Thismodelanalysesthepoints wheretheextensiondevelopersfocusonwhendesigningtheirextensions.Everyextensionisa compositeoftheelementsinthismodel.Eachextensioncanbedisassembledintoconstituent componentsintheseelementsforcomprehension.Thenitiseasiertounderstandhowtheextensions interactwiththebasesystem,howtheyacquireservicesandhowtheyprovidenewfeatures. ForexamplewhenintegratingtheOpenMRSsystemwithanexternalsystemtodirectlyinsertpatient datatothesystemskippingthewebinterface,thedeveloperswillbeworkingontheexternaleventsor inputarea.Theextensionwilladdnewbehaviorandlogictotheexternaleventsorinputsegmentofthe system.Whenthedeveloperswanttoamendthepatienttablewiththeirowncustomtablestheywill befocusingonthedatamodelarea.Inthatcasethenewfunctionalitywillbemixedwiththeexisting datamodelsegment. Mostoftheextensionscoveroneormoreblocksinthemodel.ForexampleAccessLogModule (OpenMRSAccessLoggingModule,2009)coverstheuserinterface,theservicesandthedatamodel areas.Accesslogmoduleauditsthepatientrecordmodifications.Soitwilladdnewuserinterface elementstoviewandmanagetheaccesslogs,theservicestoaccessandsavethelogsandthedata modeltopersisttheaccesslogs. Approachingthesysteminthiswayissimilartothefunctionalmodelordataflowdiagrams(Yourdon, 2006)inthestructuredsystemsanalysisanddesignmethodologythatwaspopularbeforetheobject orientedtechnologiesbecamepopular.Thereasonforhavingareferencemodelsuchasthisisthat whenanalyzinganextensionitispossibletoseethefundamentalelementsoftheextensionwithout gettinglostinthecomplexfunctionalityprovidedbytheextensionstosupportdifferentuser requirements. Thefollowingsectionswilldescribeeachpartinthediagraminfurtherdetail. UserInterface Userswillneedtoadduserinterfaceelementsormodifytheexistingelementsaccordingtotheirneeds. Forexampleusersmayneedtochangethehomepageafterauserlogsintothesystemtoshowa customizedhomepageaccordingtotherolesassignedtotheuserinsteadofthedefaulthomepageasin therolebasedhomepagemodule(OpenMRSRolebasedHomepageModule,2008).Atthemomentall 10

theextensionpointswheredeveloperscanplugintheircustomizationsareassociatedwiththeuser interfaceelements.Buttheextensionpointscanbedefinedforotherlayers. BusinessLogic/Services Userswillneedtoaddnewservicesthatarenotsupportedinthebasesystemormodifyoramendhow anexistingservicebehaves.ForexampleIDgenerationmoduleaddsuniqueIDgenerationservicesto thebasesystem(OpenMRSIDGenerationModule,2008).Sotheextensiondeveloperscancreatenew servicesintheserviceslayerandruntheminthecontainerassameasthecoreservices.Mainlynew servicesaredefinedusingthemoduleSpringbeanconfigurationwhileexistingservicesandbusiness logicaremodifiedusingtheaspectorientprogrammingmechanismdescribedlater. DataModel Userswillneedtoaddoramendtheexistingdatamodelwithnewdatastructures.ForexampleSync modulekeepsthedataintwoseparateOpenMRSinstancesinsynchronization(OpenMRSSyncModule, 2010).Theextensiondeveloperscancreatenewtablesanddatasourcesinthedatalayerandhostthem inthecontainerassameastheexistingcoredataobjects.TypicallycustomHibernatemappingsare usedtoextendthedatamodelasdescribedlater. ExternalEvents/Input Userswillneedtoacceptandreacttoeventsormessagesorimportdatafromexternalsystems.For exampleJAXWSWebservicesmoduleexposestheOpenMRSAPIthroughtheSOAPservices(OpenMRS SOAPWebServicesModule,2009).InthiscasetheJAXWSmodulefitsintotheinputelementinthe conceptualmodelexposingtheserviceelementsinparticular,APIinadifferentmediumthanthe defaultWebuserinterface. PublishEvents/Output Userswillneedtopublishmessagesoreventsaccordingtotheinternaleventsorcommunicatewithand exportdatatoexternalsystems.BIRTReportModuleexportsdataforexternalreportapplications consumption(OpenMRSBIRTReportModule,2010).InthiscaseBIRTreportmodulefitsintotheoutput elementintheconceptualmodel. Sothisconceptualmodelhelpstounderstandtheextensionsinthecontextofextensibility.When investigatingtheextensionstoseehowthecorearchitecturehashelpedthedeveloperstoextendthe systemthismodelgiveareferencemodel.Inamonolithicsystemalltheseelementsarehandledby

11

theapplicationbyitself.Inanextensiblesystemthenewextensionsfitintotheseelementsinthemodel toextendthebasearchitecture.

LimitationsoftheResearch
Thisresearchwascarriedoutmainlyinthecontextofaparticularopensourcemedicalrecordsystem. Althoughtheresultantdesignprinciplesderivedfromtheresearcharevalidforanyenterprise applicationnotlimitedtomedicalrecordsystems,theirapplicabilityandprioritycouldvaryaccordingto thefieldandthenatureofthesystem.Alsothisresearchwasconductedbyoneperson.Thereforethe investigationandtheresearchfindingsmaybeaffectedbytheviewsandpreconceptionsoftheauthor.

12

LiteratureReviewandInitialAnalysis
Extensibility
Extensibilityistheabilityofsoftwareforfuturegrowth.Itistheabilityofasystemtoextendwithnew requirementsandfunctionalitywithminimalornomodificationsinthecorearchitecture.Softwaremust staysoft,malleable.Thedisciplineofextensibilityisthetoolwhichbesthelpsusachievethis(Kelly, 2002).AccordingtoKelly,2002extensibilityworksbecauseitforcesanapproachtoproblemsbasedon thefollowingideas. 1. Anupfrontdesignwhichallowsforaddition. 2. Additionstobemadeinsmall,incrementalsteps. 3. Workelementstobeseparatedintocomprehensibleunits. Sodesigningmodularsystems,whichconsistofcorearchitectureandincrementallydevelopedsmall units,isamajorapproachtoarchitectingextensiblesystemsinsteadofconventionalmonolithic systems.

MonolithicSystemsvs.ModularSystems
Thissectionwillcomparetheconventionalmonolithicsystemsagainstthemodularsystemssuchas OpenMRS.Wolfinger,2008describestheissueswiththeconventionalsolutionswhichcraminallthe featuresusersaskforamonolithicapplication. Inthisonesizefitsallapproachtheusersneedonlyasubsetoffeaturesbuttheyhavetonavigateand usecomplexandfeaturerichsystems.Eventhoughtheapplicationtriestocaterforeveryuseritis impossibleforanenterpriseapplicationofanysizetomeetalluserrequirementsinasinglestandard product.Thereisalwayssomevariationsthatcannothandlebyastandardproduct.Enterpriseusersare conservativeaboutdeployingnewpatchesandreleases.Butwhenhavingasinglemonolithicapplication everyuserhastofacethesamedeployementprocess.Itisdifficulttoperformaselectivepatch deploymentforthespecificusers.Amonolithicapplicationishardertocustomzieoradapttospecific users.Alsoitisdifficultintegratethesystemwiththirdpartyapplicationseasily(Wolfinger,2008). Butthereareadvantagesinmonolithicapplicationscomparedtomodularsystems.Thedeveloperhas totalcontroloftheapplicationandthebehavour.Alsomonolithicsystemseliminateintegrationissues. Alargepartofissueswhichthedevelopersfaceaccordingtotheauthorsexperiencearedueto integrationofdifferentmodulesandthirdpartycomponentsworkingtogether. 13

Wofinger,2008pointsoutsomeoftheissueswithmodulararchitectures.Howcanwesupportend usersatruntimetoadaptanapplicationtochangingworkingscenarios?Howcanweautomatethe integrationofplugins?Howcanweprovideguidanceforsoftwarearchitectsondesigningcustomizable andextensiblepluginapplications?Andhowcanwemakecontractspecificationmoreeffectiveand easiertomaintain?Howcanextensibleapplicationstakeprecautionsagainstbeingtakendownbya flawedormaliciousextension?Howcanextensibleapplicationsconstrainthepermissionsofplugins? Theseareimportantissuesfacedbythedeveloperswhendesigninganextensiblesystem.Itishoped thatthisresearchwillanswerthequestion,howcanweprovideguidanceforsoftwarearchitectson designingcustomizableandextensiblepluginapplications. Pluginsystemsareinherentlyverycomplex.Differentpluginarchitectureshavetackledtheproblemto differentextent.Somearchitecturesneedtorestartthewholesystemtoeffectanypluginswhile otherscanhotdeploythepluginsinstantantly.Oneofthemostdifficultproblemsfacedbythe extensiblesystemdesignersistheinabilitytochangethesystemafterithasbeenreleasedtothewider communityorpreservingbackwardcompatibility.Soitcanbeseenthatthemodularsystemssolve manyproblemsaswellasintroducesnewchallenges.

MedicalRecordSystems
Therearedifferenttypesofmedicalinformationsystemsrangingfromclinicalpointofcare(POC) systemstopublichealthinformationsystemsfordiseasesurveillanceandstrategicdecisionmaking (WeberJahnke&Price,2007).ElectronicmedicalrecordsystemorEMRisacomputerizedinformation systemwhichstores,retrievesandmanipulatesmedicalrecordsofpatientsinahospitalorsuchan organizationthatdelivershealthcare. Severalliteraturesourcesdiscusstheattemptsinsuccessfulimplementationofmedicalrecordsystems indifferentpartsoftheworldusingdifferenttechnologies(Lober,Wagner,&Quiles,2010)(Hannan, Rotich,&Odero,2000)(Rotich,Hannan,&Smith,2003).BasicallyitispossibletogroupEMRsysteminto twocategories.ThatiscommercialEMRsystemsusedinhospitalsespeciallyinthedevelopedcountries, andtheopensourceEMRsystemsdevelopedbycommunitiestoimprovethehealthcareindeveloping countries.AccordingtotheabovesourcesthecommonchallengesforthecommunitydevelopedEMR systemsarescarcityofresources,lowlevelhardwareavailability,frequentpoweroutagesand inadequateInternetaccessandsupport.

14

OverviewofOpenMRS
OpenMRSisacommunitydevelopedopensourcemedicalrecordsystem.Theprojectisledbythe RegenstriefInstituteandthePartnersinHealthorganizationsandfundedbytheWorldHealth Organization(WHO),theCenterforDiseaseControl(CDC),TheRockefellerFoundation,andthe President'sEmergencyPlanforAIDSRelief(PEPFAR).Thedevelopmentcommunityisscatteredall aroundtheworldledbythedevelopersinIndianapolisandBoston. Mamlin,etal.,2006describesthebeginningsoftheprojectpriortothecurrentOpenMRSwas conceived.IndianaUniversitySchoolandMoiUniversitySchoolofMedicinecollaboratedtocreatethe MedicalRecordSystem(MMRS)whichwasdevelopedusingMicrosoftAccessandwhichwasdeployed inKenya.ThesystemwasusedinAMPATH(AcademicModelforthePreventionandTreatmentof HIV/AIDS)project.Thesystemwasnotadequatetosupportmanylocationsandtohandlehundred thousandpatients.AfterevaluatingexistingsolutionstheycameupwithAMRS.AMRShasanextensible datamodel.Insteadofaflattablestructurewhereeachpatientdatapointisrecordedbyacolumn, AMRSmodelusesthestackeddatastructureorentityattributevalueapproachwhereasinglerowof dataisrepresentedbyastackofrowsforeachpatient.Thisisdiscussedlater. ThedesigngoalsofAMRSwerecollaborationofthecommunitytobuilduponacommoninfrastructure, scalabilitytosupportmanylocationsandhundredthousandpatients,flexibilitytosupportnotonlyHIV carebutgeneralclinicalscenarios,rapidformdesignfordataentry,clinicallyusefulgatheringofdata, useofstandardsthemedicalfieldsuchasHL7,LOINC,ICD10,SNOMEDandCPT,supporthighquality researchusingthecaptureddata,webbasedwithsupportforintermittentconnectionsindeveloping countriesandlowcostsolutionusingfreeandopensourcetools(Mamlin,etal.,2006).AMRSsystem wasdevelopedusingPython,PloneandMySQL. Wolfe,etal.,2006describeshowtheAMRSteampartneredwiththePartnersinHealthtoformthe currentOpenMRSprojectin2004whichreplacedtheaboveAMPATHproject.PartnersinHealthwere involvedindevelopingasystemtosupportmultidrugresistanttuberculosisstudiesinPeru.Thegoalof thecollaborationwastocreateanapplicationprogramminginterface(API)encapsulatingthedata modelandtodevelopawebbasedapplication.TheAPIisseparatefromthewebinterfacesuchthatthe APIcanbeaccessedthroughothermediumssuchasmobileappliances.Thismeansthatthedata gatheringanddisseminationisnotconstrainedintoisolatedsilos.TheuserinterfacecouldbeWindows applications,Javaapplications,Webapplications,programsrunninginpersonaldigitalassistants,voice

15

recognitioninterfacesthroughphonesorscannedpaperformsconsumedbyopticalcharacter recognition. Althoughagenericsystemwillnotsupportallthefeaturesoutoftheboxitshouldbeextensiblesothat developerscanextendthesystemtosupporttherequirements(Fraser,Biondich,Moodley,Choi, Mamlin,&Szolovits,2005).Thedatamodelplaysamajorpartinextensibility.OpenMRSusesaconcept dictionarywherethedatapointsarefirstdefinedinthesystem.Thepatientdataarecapturedusing thesecodeddata.Usingcodeddatainsteadoffreetextgivesmoreversatilityandsearchand manipulationcapabilities.Alsothedatacanbecomparedbetweensystemsaccurately.Theextensible datamodelwillbediscussedinthechapterFurtherAnalysisofExtensibilityPrinciples. Theabovepaperscoverthehistoryoftheproject,howitcameintoexistence,theaimsoftheproject andsomehighlevelrequirements.Accordingtothecoredevelopersinterviewedtheexistingdata modelhasevolvedfromthelessonslearnedfromaround30yearsofpracticalexperienceinvarious projectsincludingtheAMPATHproject.

OpenMRSArchitecture
ThefollowingsectionwillgiveabriefdescriptionabouttheOpenMRSmedicalrecordsystem.This researchwillnotgointoelaboratedetailonmedicalrecordsystemsasthemajoraimofthisprojectisto comeupwithimportantdesignprinciplestowardsextensibility. TheprojectusesopensourcetoolsandtechnologiessuchasJava,Springframework,SpringMVC, Hibernate,MySQL,jQueryandDWRandtoolssuchasEclipse,BIRT,Ant,Subversion,BambooandJIRA. OpenMRShasanextensibledatamodelandpluggablemodulearchitecture.Thefollowingdiagram illustratesthetoplevelarchitecture.

16

Modules

Web Services Data

Figure3OpenMRStoplevelarchitecture

Broadlythesystemconsistsofthreelayersasshownabove.Thatisdata,servicesandweb.Thedata layerconsistsofthedatabaseaccessservices.Thebusinesslogicresidesintheserviceslayer.Andthe weblayerconsistsofthedefaultwebapplication.Itshouldbenotedthatthesystemcanbeused withouttheweblayer.InthatcasethedevelopercaninteractwiththeservicesdirectlyusingtheAPIof theservices.Themodulesconnecttoallthreelayerstoextendthesystem. OpenMRSusesmodulestoextendthefunctionalityofthesystemsodeveloperscanwritenew extensionsandplugthemintothecoresystemseamlessly.Themodulescansupportnewadditionsin thepersistencelevelorintheserviceleveloraddormodifythewebbaseduserinterfaceorconnecta differentuserinterfacesystemtothecoresystemaltogether.Forexamplethedevelopercancreate newdatabasetablesorappendorreferenceexistingtables,orintheuserinterfacetheycancreatenew userinterfaceelementsorreplaceexistingelementsusingtheextensionpoints.Thesewillbediscussed indetailwithexamplesinthechapterFurtherAnalysisofDesignPrinciples. TheOpenMRSmodulesusevarioustoolssuchasJasperReports,Xtreamandintegratewithproductslike PentahosuiteoftoolssuchasKettle.TheEclipseIDEhasbeenextendedwithOpenMRSspecificplugins tohelpthedevelopersbuildmoduleseasily.OnenotableexceptionisthattheprojectusesMicrosoft InfoPathproprietarysoftwareforformentrytask.Accordingtotheinterviewsitwasusedbecauseat thetimewhenthesystemwasdevelopedtherewasnoalterativesolutiontosatisfytherequirements withlesseffortandtime.AnXFormsbasedformentrymodulewasdevelopedlater.Analternativeweb basedHTMLformentrymodulehasbeendevelopedandisunderactivedevelopmentnow.Whileolder implementationsitesusetheInfoPathforms,newimplementationsareusingthenewHTMLbasedform entrymodule.Thesemodulefunctionalitiescanbecategorizedintotheinputelementintheconceptual modeldescribedearlier.Theyprovideanalternativeinputmethodforpatientrecorddata. 17

OpenMRShasbeendeployedinmanycountriessuchasKenya,Rwanda,Tanzania,SouthAfrica, Lesotho,Zimbabwe,Mozambique,Uganda,PakistanandUSA(OpenMRSImplementations,2010).The systemrunsinregionswithlimitednetworkavailabilityandlowresources.Otherthanbeingusedasa generalpatientrecordsysteminhospitals,itisusedintheHIVtreatmentinKenya,Rwanda,Tanzania, multidrugresistanttuberculosisstudiesinPeruaswellasforpediatricclinicsinIndianaand tuberculosistreatmentclinicsinLosAngeles,USA. Eachofthesedifferentimplementationsiteshasdifferentrequirementsandexpectationsfromthebase system.OpenMRScannotsatisfyalltheserequirementsoutofthebox.Sothedesignershavebuiltthe systemwithextensibilityinmind.Thedatamodelisextensibletosupportthesevariedrequirements. Implementerscandesignthedatamodeltosuittheirrequirementsandatthesametimemakesure thattheinformationthatisstoredcanbetransferablebetweendifferentimplementations. SowhenapplyingOpenMRSsystemtorecordpatientdataintheHIVtreatmentprograms,tuberculosis studies,pediatricclinicsOpenMRSdevelopersdonotreleaseanewOpenMRSversioneverytime. InsteadOpenMRSbasesystemisastablesystemwithitsownreleasecycle.Implementerswhoare deployingtheEMRsysteminsitesapplytheextensibledatamodelandusemodulestobuildacustom EMRsystemoutofthebasesystem.Thedeveloperscancreateamoduleandincludenewfeaturesor customizationswithoutwaitingforthecoredevelopersaddingthefunctionality.Recentlythereporting functionshavebeenportedintoaseparatemodulesothatreportingdeveloperscanshipthemodule independentlyfromthebasesystem.Alsothelogicservicewhichisaprocesswheredataaswellas deriveddatacanberetrievedaboutpatientsinahighlevelmannerwhichisusedfordecisionsupport ruleshasbeenmovedintoaseparatemodulesothatthedevelopmentcangoinparallel. OpenMRSisbasedontheprinciplethatinformationshouldbestoredinamannerwhichiseasyto analyzeandaggregate.Thatisitencouragestheuseofcodeddatainsteadoftextualfreeflowing information.Atitscoreithasaconceptdictionarywhichisarepositoryofmetadataof relevantsymptoms,diagnosis,drugs,tests,visitsandotherrecordablequestionsandanswers.Initially theOpenMRSsystemisemptyofanymetadata.Theimplementorfillstheconceptdictionaryaccording totheusage.ForexampletheimplementorcanentertheconceptBloodTypeandtherelevantanswers A,B,AB,Oconceptsastheanswers.Thenontheuserscanusetheseconceptstocreateformsaswellas filltheformswiththepatientdata.Thiswillbefurtherdiscussedinthedescriptionofthekeyvaluedata modelsection.

18

Softwaretakesonmanyoftheattributesoftheorganisationandprocessthatcreatesit(Kelly, 2002).Conway'slawsaysorganizationswhichdesignsystemsareconstrainedtoproducesystemswhich arecopiesofthecommunicationstructuresoftheseorganizations.OpenMRScommunityconsistsof developers,usersandvolunteersscatteredaroundtheworldworkingfordifferentorganizations.Hence thearchitectureshowstheattributesofopenness,loosecouplingandhighuserinvolvement.

ModuleArchitecture
Theimportanceoflearningthemechanicsofthemodulearchitectureisthatthisisakeyfeaturethat providesextensibilityinthemedicalrecordsystem.Todaymanyofthesoftwaresystemsincorporatean extensionmechanismtodifferentdegrees.ForexampleEclipsehasthepluginarchitecture.JBoss applicationserverisbasedonamicrokernelarchitecturewheredifferentcomponentsplugintothat base.EvenAdobePhotoshopapplicationhasanextensionmechanismsothatdeveloperscanaddnew featurestotheexistingtoolset.Byunderstandingthemodulearchitectureitwouldhelpcomprehending thedesignprinciplesbehindthesefeaturesinpracticaltermslater. ThegoaloftheOpenMRSmodulearchitectureistoallowotherdeveloperstoenhanceandextendthe OpenMRSsystemtosatisfytheirspecificrequirementswithoutmakingchangestothecorecodeofthe OpenMRS.ThemodulesystemhasbeenavailablesinceOpenMRSversion1.1. OpenMRSdefinesaspecificstructureforamodulesimilartotheJavaWARfilewhichbundlesaJava Webapplication.Seetheappendixmodulefolderstructure.Themetadataareprovidedbythefilecalled config.xml.Asampleconfig.xmlfileisprovidedintheappendixsamplemoduleconfigurationfile.When startingupamoduleOpenMRSreadsthisfileandregisterstheprovidedextensionswithsystem.Some ofthedetailsprovidedintheconfigurationfilearelistedbelow. Themodulename Themoduleversion SupportedOpenMRSversion Dependenciesonothermodules Theactivatorclasswhichdefinestheinitializationandcleanupcode Extensionpointsthismoduleprovides

InAdditionthereisamoduleapplicationcontextfile.ThisisanormalSpringbeansconfigurationfile whichdefinestheservicesprovidedbythemodule.Seeasamplefileintheappendixsamplemodule

19

applicationcontextconfigurationfile.Thecorearchitectureloadsthesemodulespecificserviceson modulestartup. ForthepersistencelayerOpenMRSloadsupthecustomHibernatemappingsprovidedinthemodule folderstructure.ThedatamigrationishandledbyLiquiBasedatamigrationlibrary(LiquiBase,2010). Untilversion1.4OpenMRShadacustomdatamigrationmechanism(OpenMRSSqldiff,2008).Itwas foundtobeverylimitingwhenrunningcomplextasksotherthansimpleSQLcreatetable,insert statements.

ExtensionMechanism
Thissectionwilldiscusshowanextensionmechanismisdesignedinsoftwareapplicationsandcompare itwithhowtheOpenMRSarchitecturedesignedit. Anyextensionmechanismconsistsofthreemajorparts. Definingtheextensionpointhooksinthebasesystem Apluginregistrywheretheextensionpointsprovidedbythepluginmodulegetregisteredwith thebasesystemhooks. Atriggeringmechanismthatcallstheextensioncodewhenanextensionpointisactivated.

Thereareseveralmethodstoimplementthismechanism.Thefollowingsectionsdescribetwowaysthat canbeused. ImplementingInterfaceContracts Programminglanguagesprovidetheconceptcalledinterface.Interfaceisacontract.Corecodedefines interfacesorabstractclassesatextensionpoints.Themodulecodeimplementstherelevantinterfaces orsubclass.Onmodulestartupthecodethatimplementstherelevantinterfacesgetregisteredina systemwideregistry.Thiswaywhenauseractiontriggerstheextensionpointtherelevantmethodsin themodulearecalledthroughtheinterfaces.Thecontextdatawillbepassedtothecallingmethod. Usinginterfacesisthesimplestmethod.Theweaknessisthatthisisnotflexible.Thebasesystemand thepluginsshouldfollowtheinterfacesstrictly.Theycannotbemodifiedeasily. PublishingEvents Thebasesystemdefinesapreconfiguredsetofstaticevents.Theeventscouldbedefinedasconstants orenumsintheprogramminglanguage.Foreveryextensiblepointthebasesystemsendsoutastatic event.Theeventcontainsthedetailsaboutthecontextinwhichitwastriggered.Themodulessubscribe 20

toreceivetherelevantevents.Modelviewpresenter(MVP)designpatternpopularizedbytheGoogle WebToolkit(GWT)recommendsthismechanisminimplementingtheuserinterfaces(Ramsdale,2010). Oneofthemainadvantagesinthisapproachisthattheeventsourcesandeventconsumersare completelydecoupled. OpenMRSImplementation OpenMRSusesaninterfacecontractbasedmechanism.Allextensionclassesderivedfromtheparent Extensionclass.Forexampletoaddanewmenuitemtotheadministrationsectionthemodule developersubclassestheAdministrationSectionExtclassanddefinesthelinksasakeyvaluemap.Inthe basesystemadministrationpagetheextensionpointisdefinedusingintheJSPasataglibraryaction, <openmrs:extensionPointpointId="org.openmrs.admin.list">.Whendisplayingtheadministration sectionthebasesystemenumeratestheregisteredmoduleextensionsandletthemgeneratethe presentationelementswhichseamlesslyplugsintothecoresystem.

StylesforExtensibility
Whenconsideringextensibilityinsoftwarearchitectureitisimportantunderstandthestylesof extensibilityingeneral.Allen,2001describesthreestylesofextensiblesystems.Theyareblackbox, glassboxandwhiteboxsystems. Blackboxsystems Blackboxsystemsarethosewhichtheoutsideprogrammerhasneithertheabilitytoviewormodifythe underlyingcode.Mostofthecommericalsoftwarefallintothiscategory.ForexampleInternetExplorer supportsaddingextensionswrittenbythirdpartydevelopers.TheInternetExplorerprovidesapublic APIdescribingtheavailableinterfacesbuttheydonotprovidetheunderlyingcode.Thismethodof extensibilityisthemostrestrictiveofall. Glassboxsystems Glassboxsystemsmeanthedeveloperhastheabilitytoseetheunderlyingcodeofthebasesystembut cannotmakechangesorenhanceit.Thiswaydevelopershaveaninsightofhowtheirextensions integratewiththebasesystem.Mostopensourceprojectsfallintothiscateogrywhenlookingfromthe perspectiveoftheusers.

21

Whiteboxsystems Inwhiteboxsystemsthedevelopershavetheabilitytoseetheunderlyingcodeandtheycanmake changestothecorecodeasrequired.Opensourceprojectsfallintothiscateogrywhentheusers requestandprovidechangestothecorecode. Analysis OpenMRSmodelisawhiteboxsystem.Thisisclearysupportedbybeinganopensourcesystem.Whena deficiencyispointedoutinthebasesystembythemoduledevelopersOpenMRScoredevelopersare quicktoamendthesourcetofixitortogiveanalternativeworkaround.Thiswaythebasesystem evolvestosupportnewextensionsinsteadofaddingnewfeaturestothebasesystem.Forexamplenew extensionpointsgetdefinedintheuserinterfacewhenthemoduledevelopersrequestthem.According tothecoredevelopersmostofthetimetherequiredamendmentstothecorearchitectureareprovided bythemoduledevelopersthemselvesassourcecodepatcheswhichconsequentlyaddedtothecurrent developmentcycle. SoOpenMRSarchitectureisuniqueandadvantageousinthissensebeinganopensourceproject.In commercialclosedsourcesystemstheextensiondevelopersdonothaveaccesstothesourceofthe coresystem.

ModuleLimitations
ThefollowingsectionsdescribesomelimitationsoftheOpenMRSmodulearchitectureinbrief.When incorporatingextensibilityprinciplesthedesignerhastokeepinmindtheseissues.Thesewere extractedinthedatagatheringphase.Intheinterviewsitwasevidentthatthedesignersdidnot considertheseissuesthroughlywhendevelopingtheextensionmechanisminitially.Accordingtothe discussionssomeoftheissuesfacedbythedevelopercommunitywhenwritingextensionsarerelated totheselimitations.Soitisimportanttodiscusstheseissuesinheretounderstandthelimitationsofthe currentarchitecture. TrustworthyComputing Confidentialityandprivacyareimportantattributesinsoftwaresystemsandparticularlyinthemedical recordsystemswhereregulationslikeHIPAAareenforced(Annas,2003).OpenMRSarchitecture inherentlytruststhemoduledevelopers.AnOpenMRSmodulecandoanythingthecoreOpenMRScode basecando.Itcanretrievepatientdata.Itcandeleteallthepatientdata.Itcansendpatientdatatoan externaldestination. 22

OpenMRSprovidesagranularlevelsecuritymodelfortheauthorizationofthesystemfunctions.Auser hasoneormoreroles.Aroleconsistsofoneormoreprivileges.Usingthisroleprivilegemodel OpenMRSimplementerscandefinearolewhichcanviewpatientsbutcannoteditthepatientdataora rolewhichcanloginandmanagescheduletasksonly.

User
Figure4Privilegerolemodel

Role

Privilege

Moduledevelopersusethisprivilegemodeltosecurethemodulefunctionality.Forexampleprivileges canbedefinedwhichcanviewthemodulesnewpages.Butthebasesystemcannotcontrolwhat modulescandoorcannotdo. Sotherearetwoperspectivesconcerningthesecurityofthesystem.Thatisuserlevelandextension level.IntheOpenMRSarchitecturetheextensionmechanismusestheexistinguserlevelauthentication andauthorizationfeaturesprovided.ButOpenMRSmodulearchitecturedoesnotprovideanextension levelsecuritymodel.Thatmeansthecoresystemcannotcontrolwhatanextensioncandoorcannot do. Fromtheinterviewsitwasfoundoutthatthisrequirementwasnotmajorissueinrealworldscenarios. Ontheotherhandthedevelopersexpressthatincorporatinganextensionlevelsecuritymechanism couldchangethecoresystemconsiderably.Sooneoftheemergingdesignprinciplesofthisresearchis designforsecurityfromtheinception.Thiswillbediscussedfurtherintherelevantdesignprinciple discussion. PreservingBackwardCompatibility Oneofthelimitationswhendoingradicalenhancementtothemodulearchitectureistheneedfor preservingbackwardcompatibility.Whenchangingthebasecodethedevelopershavetotake precautionsnottobreaktheoldmodules.ThismeanstheOpenMRSdevelopershavetopreserve inelegantpartsofoldcodewhenrefactoringthebasesystem. Thecoresystemdevelopersinterviewedsaythattheydidnotfindconsiderabledesignchangesthat couldbreakthebackwardcompatibilitysofar.Alsoanimportantfactpointedoutattheinterviewswas thatbecausealmostallthemodulesourcecodeisavailableintherepositoryitwaseasytochangeor upgrademodulestosupportanewerOpenMRSversioniftheneedarises.Inthesystemswhere 23

extensionsourceisnotcentrallyheldorisprivate,breakingthebackwardcompatibilitycoulddisrupt manyusers. Soitisimperativethatanextensiblearchitecturehastobedesignedrightfromthebeginning. Otherwiseitismuchmoredifficulttochangethedesignwhenitisreleasedtothepublic.Itishoped thattheemergingprinciplesofthisprojectwillhelpthedesignerscomeupwithanextensible architecturerightfromthefirsttime. IntrospectiveFeatures OpenMRSarchitecturelacksintrospectionfeatures.Eachmodulelivesinanisolatedcontainer.Theyare notawareofthesurroundingecosystemcreatedbytheothermodulesotherthantheexplicitly specifieddependenciesinthemoduleconfiguration.Sothislimitsintermoduleextensibility. Themoduledeveloperswhowereintervieweddidnotfindthisalimitationsofar.Onereasonthisisnot relevantinthiscaseisthattheprojectandthemodulesareopensourceanddevelopedcooperatively bythedevelopercommunity.Ifthiswasaclosedsourcesystemthiswouldhavebecomeanissue. IncompleteModuleInitializationandCleanup AmoduleusesaclassderivedfromtheActivatorclassfortheinitializationandcleanup.Thisisdefined inthemoduleconfiguration.EachmoduleloadsupinaseparateJavaclassloader.Soeachmoduleis isolatedfromothermodules.AtthetimewhentheactivatorgetscalledtheSpringconfigurationisnot fullyloadedandtheservicesarenotactive.Thishascausedmanyissuesforthemoduledevelopers recently.Furtherdevelopmentinthisareaisnecessaryforimprovingtheextensibilityofthesystem. Asstatedsomeoftheabovelimitationscanbeovercomeiftheemergingprinciplesarefollowed.It shouldbenotedthatothermedicalrecordsystemswhichwererevieweddoesnotprovideabroad extensiblearchitectureasinthisparticularsystem.Althoughtheyhaveacomponentizedarchitecture madefromdifferentreadymadeapplicationstheyarenotextendableasinOpenMRS.

ExtensibilityinOtherPlatforms
Thissectionwilldiscussbrieflyotherextensiblesystemsincontext.Todaymanyapplicationsprovide pluginmechanismsorscriptingframeworkssothattheuserscancustomizeandextendthe functionalityofthebasesystem.Asampleofextensiblesystemsislistedbelow. MicrosoftExcelmacrofunctionsallowtheusertowritecustomcalculations.

24

MicrosoftOfficeapplicationsprovidescriptingfacilities. TheuserscanprogramgamessuchasDoomandchangethenormalbehavior. Firefoxpluginsystemallowsaddingnewuserinterfaceelements. AdobePhotoshoppluginsaddnewfiltersandimagemanipulationtools.

ItisapparentthatwhendesigningtheOpenMRSmodulearchitecturethedevelopershadusedthe extensionpointsdesignsimilartotheEclipsepluginarchitecture.Eclipseplatformisamultilanguage integrateddevelopmentenvironmentwithanextensiblepluginsystem.Inadditiontothesoftware developmentenvironmentEclipseprovidesageneralpurposerichclientplatformfordeveloping desktopsoftware.Clayberg&Rubel,2006explainstheEclipsepluginarchitectureindetail. IntheinterviewswiththeOpenMRSdevelopersitwasrevealedthattheyhavelookedintousingthe OSGiplatformfortheOpenMRSpluginsystem.Evenatthemomentitisanitemintheagendafor futuredevelopmentworkinOpenMRS.OSGiisanopenmodulesystemforJavaprogramminglanguage thatprovidesadynamiccomponentmodelandaserviceplatformforJavacomponents.Tavares& Valente,2008givesintroductiontotheservicesprovidedbyOSGi.AttheinceptionofOpenMRS development,OSGiwasnothugelypopular,thedeveloperswerenotknowledgeableenoughaboutthe subjectandtheproductionuseofOSGihasbeenlimited.Sotheydecidedtoimplementtheplugin systemfromthegroundup.TherearedefecienciescomparedtoOSGiintheOpenMRSmodule architecture.ForexampleinOpenMRS,differentversionsofthesamemodulecannotbeloaded.

OtherMedicalRecordSystems
SomeofthepopularandwellestablishedmedicalrecordsystemsareEMRSolutions(EMRExperts, 2010),PRAXIS(PRAXIS,2010)andChartingPLUS(MediNotes,2010).Theseareallcommercialsoftware systems.ThesesystemsaresimilartoERPsystemsusedinorganizations.Thesystemsconsistofmany integratedcomponentswhichanorganizationcanpurchaseaccordingtotheirrequirements.The componentsaredesignedinageneralpurposemannerwithnumerouseconfigurableoptions.Thereare differenttypesofmodulessuitableforopthalmologiststolabrotorywork.Alsothereareserveralopen sourcemedicalrecordsystemsinusetodayincludingOpenEMR(OpenEMR,2010)andVistA(VistA, 2010). FromthebroadinvestigationitwasfoundthatOpenMRSdiffersfromtherestoftheEMRsystemsand opensourceprojectsinparticularinthatitprovidesagenericleansystemnotspecifictoanyfieldwhich canbeextendedorcustomizedusingthedatamodelandextensionsaccordingtotheusage.OpenMRS 25

canbeperceivedasacleanslatewheredifferenttablesandnotescanbedrawnbytheuserstodesign theirownformula.OpenMRSenablestheimplementerstodesignacustomizedmedicalrecordssystem usingitscommonframeworkandmodules.Itisbasedonaconceptualtablestructureindependentof metadatainanyspecificmedicalfieldoranyparticulardatacollectingforms,sothatitcanbe customizedfordifferentpurposes.Iftheexistingfeaturesarenotenoughthedeveloperscanaddthe missingfeaturesbywritingmodules.Theresearchwillnotdiscussothermedicalrecordsystemsindetail becausetheobjectiveisoncomingupwiththekeyconceptsbehindtheextensiblearchitecture.

26

DesignPrinciplesOverview
Asthestartingpointinidentifyingthedesignprinciplesexistingliteraturewereinvestigatedtobuildon afoundation.Theinvestigationrevealedthatthedesignprinciplesspecificfordesigningextensible architecturewerelackinginliterature.Itishopedthattheoutcomeofthisresearchwillfillthisgap. Intheliteratureanalysis,Martin,2000providedarichsetofprinciplestoformulatethebasisofthis research.Althoughthesedesignprinciplesarenotspecificforextensibilitymostofthemarerelevantfor designingextensiblesystems.Thefollowingarebriefdescriptionsofsomeimportantconceptsfrom Martin,2000andotherreferencedsources.Itshouldbenotedthattheseprinciplespavethefoundation forthedesignprinciplesemergedfromthisproject.

OpenClosePrinciple
Meyer,1988saysamoduleshouldbeopenforextensionbutclosedformodification.Whenwriting classes,packagesormodulesitshouldbepossibletoextendthecodewithoutchangingtheoriginal code.Polymorphisminobjectorienteddesignfaciliatesthisprinciple.Changingtheoriginalcodewould introducenewbugsandissueswithbackwardcompatibility.Butitispossibletoarguethattheextended codecouldchangethesemanticsofthecodewhichwouldbreakthesystembehaviour.OpenMRS implementationsareextendedthroughtheextensionpoints,aspectorientedprogramming mechanisms,withoutmodifiyingthebasesystemasdesribedlater.

Liskov'sSubstitutionPrinciple
Liskov,1987saysderivedtypesmustbecompletelysubstitutablefortheirbasetypes.Thisprincipleisan extensionfromtheopencloseprinciple.Inobjectorienteddesign,Liskovssubstitutionprinciplecanbe appliedbyusingclasshierarchiesandinterfaces.Thebasetypeworksasacontractforotherderived classestofollow.Thisisthebasisofhowmoduleextensionpointswork.Thebasesystemprovides interfacesandtheextensionpointsimplementtheinterfaces.

InterfaceSegregationPrinciple
Manyclientspecificinterfacesarebetterthanonegeneralpurposeinterface(Martin,2000).Eachclass, package,moduleorlayershoulddoonething.Interfacesegregationpromoteshighlycohesive components.Thisisrelatedtothesingleresponsibilityprinciple. ForexampleActivatorclassesintheOpenMRSmodulesperforminitializationandcleanuptasksofthe module.Iftheclasshandlesothertasksbreakingtheinterfacesegregationprinciplethenthemodule 27

developerhastoimplementtheseunusedtasksintheirimplementation.Thismakestheoveralldesign complexandunwieldy.

DependencyInversion
Dependencyinversionprinciplemeansdependuponabstractions.Donotdependuponconcretions (Martin,2000).Dependencyinversionhasbeenapopulardesignconceptintherecenttimeswiththe widerusageoftheframeworkssuchasSpring.Dependencyinversionpromotesloosecouplingbetween components. OpenMRSusesdependencyinversionheavilybecauseitisusingtheSpringframework.Dependency inversionisevidentinthepluginarchitectureatthetoplevel.Thebasesystemworkswithzeroormore pluginmodules.Itdoesnothaveadirectdependencyonmodules.Atthesystemstartupthemodules areloadedandthecustomfunctionalitiesareaddedtothebasesystem.

DerivedPrinciples
Intheabovesectionssomeoftheimportantgeneraldesignprinciplesinliteraturewerediscussedusing observationsfromthesoftwarearchitecture.Withtheuseofobjectorienteddesignintheindustrythe aboveprinciplesarewellestablishedinthedevelopercommunityandhaveawiderusageinthecurrent bestpractices.Todaydevelopersusetheseprincipleswithoutanyconsciousthoughtandtheyarewell supportedinthemodernprogramminglanguagesandtools. Thisresearchprojectattemptedtogobeyondthesedesignprinciplesandidentifysomekeyhighlevel designdecisionsthatarepertinentforextensiblesystemsdevelopment.Althoughtheconceptsare specificallyextractedfromthemedicalrecordsystemorinparticularOpenMRS,theseconceptsare universallyvalidforanyextensiblearchitecture. Followingarethetechnicalandhumanfactordesignprinciplesformulatedfromthisresearch. Aspectorienteddesign Singleresponsibilityprinciple Generalization Keyvaluedatamodel Leverageandreuseexistingtools Usercentereddesignandpublicdesignprocess Internalizationfrominception 28

Principleofusingmetaphor Useofstandards Securityfrominception

Theseprinciplesarespecificenoughthattheycanbeappliedintherealworldenterpriseapplication developmentscenarioseffectivelyasbestpracticesandachieveextensibilitybutgenericenoughsothat theycanbeappliedinanyindustrynotspecifictomedicalrecordsystems. Alsotheseprinciplesdonotstandinisolation.Theyhaveinterdependencies.Forexampletheuseof standardsimpliesleveragingandreusingexistingtoolsprinciple.Theseconceptsworkinsynergy. Appliedtogethertheyimprovetheextensibilityofsoftwarearchitecturecohesively. Thenextchapterswillanalyzeeachoftheabovedesignprinciplesindetailusingexamplesfromthe OpenMRSsystemandarguethevalidityandeffectivenessofthechosenprinciplesinrealworld scenariosbasedontheOpenMRSarchitecture.

29

FurtherAnalysisofDesignPrinciples
Thischapterwillfurtheranalyzetheaboveidentifiedprinciplesthatarethebasisfortheextensibilityin theOpenMRSarchitecturewiththeevidencefromtheOpenMRSarchitecture.

AspectOrientedDesign
AspectorientedprogrammingorAOPisaprogrammingparadigmwhichisolatessupportingfunctions fromthemainbusinesslogic.Thesesecondaryfunctionsarecalledcrosscuttingconcernsinaspect orientedprogramming.Someofthecommonexamplesofthecrosscuttingconcernsarelogging, auditingandtransactions.TheSpringframeworkwhichisthebaseframeworkusedinOpenMRSuses aspectorientedprogrammingheavilytosupporttransactionsetc. Inaspectorientedprogrammingtheprogrammercandefineapieceofcodeofsupportingfunction whichiscalledtheadvice.Thepointcutsarethepointsintheprogramwheretheadviceneededtobe executed.Forexamplebeforecallingaspecificmethod,aftercallingaspecificmethodorwrapping callingaspecificmethodaresomeofthepointcutsinaprogram.Thecombinationoftheadviceandthe pointcutistheaspect.RelatedtoAOPthereareseveraldesignideassuchascollaborationbaseddesign, subjectorientedprogrammingandadaptiveprogrammingasdescribedinZenger,2004. Althoughaspectorienteddesignisconcernedwithcrosscuttingconcernssuchasloggingand transactionsitcanbeusedtoextendormodifyaclosedsystemwithoutmodifyingthecoresystem.For exampletheprogrammercanwriteanadvicecodewhichwouldcallaWebservicetoupdatean externalpatientrecordsystemwhenthepointcutofsavePatient()methodofthePatientDAOinthe basesystemiscalled.ThisusageiscomparabletothechainofresponsibilitypatterninGamma,Helm, Johnson,&Vlissides,1994.Themoduledeveloperisregisteringforthesavepatientevent.Whenthe savepaitenteventoccursthebasesystemcallsthecustommodulecode.Whatisintersertingisthatthe advicecanwraptheoriginalcode.Henceitcanfilterorcompeletystoptheoriginalcodefrom executing.Inthiscasetheoriginalsourcecodeisnotmodified. TheOpenMRSusesthisconceptheavilyforextendingthesystem.OpenMRSallowsregisteringadvice codetoanyservicemethodcallpointcutsusingthefamiliarSpringframeworkaspectoriented programmingstyle.Bywritingadvicecodetheprogrammercanenhanceandextendtheexisting functionalityofthecorecodebaseorcompletelychangethesymanticsoftheexistingcodeby overridingtheoriginalcode.

30

ThispowerfulmethodofhookableAPIhasastrongdisadvantage.Thatisthemodulescanchangethe logicoftheoriginalcodeinradicalfashion.Forexampletheprogrammercanwriteaspectcodetosaving patientandsavethepatientinaremotesystem,ortheretrievingthepatientmethodcanbeextended bylookingupthepatientdatainaremotesystem.ThismeansOpenMRShasnocontroloverthe behaviourwhenmodulesareinstalled.Theadvicecodecouldbreakthelogicorthenormalbehaviour expectedbytheuser.Thisisapowerfulmethodofopenforextension,closedformodification principle(Martin,1996). ItshouldbenotedthatAOPisawellestablishedconceptinthedevelopercommunity.Thereasonitis highlightedinthisresearchasaconceptisthattheusagediffersfromtheuseofitinconventionalcross cuttingconcernstoalteringbehaviormechanismsoroverridingmechanismscompletely.Forexample aspectorienteddesignisnotjustusedforloggingortransactions.Itisusedtooverridefunctionssuchas overridingthepatientdataenteringprocesswithacustombehavior. Majorityofthemoduledeveloperswhowereinterviewedstatedthatthiswrappingofexistingfunctions usingaspectorientedprogrammingisoneofthestrongestpointsofOpenMRSextensibility.Theyrated thisasthemostimportantextensibilitymechanism.Accordingtotheinterviewedcoredevelopersone ofthekeyadvantagesofaspectorienteddesignisthattheydonotneedtoaddanyspecificmechanisms inthecorearchitecturetosupporttheaspectorientedprogramming.Everymethodcallcanbe overriddenorextendedthroughAOPbythemoduledevelopersimplicitly.

SingleResponsibilityPrinciple
OneofthebasicprinciplesoftheUnixoperatingsystemdesignismakeeachprogramdoonething well(McIlroy,Pinson,&Tague,1978)Thisisanimportantdesignprincipleforextensiblesystems.A classshouldhaveonlyonereasontochange(Martin,2002).Eachclasswillhandleasingleresponsibility. Whenmakingchangestoaclasshavingmorethanoneresponsibilitythechangemightaffectother functionality.Thisiscalledtherippleeffect.Therippleeffectdemonstratesthefrictionthatcanoccur whenchangesaremade.Ifthesechangesarewithinthesamemodulethenthefrictionislessbecause thechangesarenotvisibleelsewhere.Thebiggerthechange,themoremodulesinvolved,thegreater thefriction(Kelly,2002).

31

mcanbebrok kenupintosm mallerandsm mallerproblem msuntilitise easytocompr rehend.Any y Aproblem problemincomputers sciencecanbesolvedwith hanotherleve elofindirectionisafamo oussaying attributed dtoDavidWh heeler(Wilson n&Oram,2007).Atthehi ighestlevelO OpenMRSdefi inesastrict layeredar rchitectureea achwithasin ngleresponsib bility.Thisisd describednex xt.

WebUI

Mob bile

APIServ A vices DataAcc D cess Databa ase

Figure5Lay yeredarchitecture

OpenMRS Shasalayere edarchitectur rewitheachlayerhavinga asinglerespo onsibilityassh howninthefigure above.Ea achlayerconsumesthese ervicesofthelayerbelowa andprovidesservicestoth helayerabov ve. Eachlayerhasaclearly ydefinedbou undarywiththeadjacentlayers.Theselevelsofabst tractionsimplify m.Amultitier rarchitecture eimprovesfle exibility,extensibilityandm maintainability. thesystem Forexamp plethedefau ultwebbased duserinterfac celayerofOp penMRScanb beswappedw withanotheruser interfaceimplementat tiontosupportdifferentm mobiledevices sandmultipleenvironmen nts.OpenDat taKit ntationwhichwasimplementedonthemobilephon nestocollectdatafromce ell wassuchanimplemen nsteadoftheconventional lWebapplica ation(Anokwa a,Hartung,Brunette,Borr riello,&Lerer r, phonesin 2009).Thereasonthiscanbedoneeasilyisthattheuserinte erfacefunctio onalityisisola atedinasingle hepresentationcodeismi ixedinwiththeservicesla ayerorthepe ersistencelay yercodethenit layer.Ifth wouldbehardertosw waptheuserin nterfacelayer. Oneexam mpleisinthelayeredarchitecture,OpenMRSdevelo opersdonota allowHiberna atespecificlo ogicto creepinto ootherlayers s.Hibernates supportsanim mplicitvalidat tionmechani ism.TheHibe ernatevalidat tor canreadt themetadata afromtheHib bernatemapp pingsandvalidatethedom mainobjects.ButOpenMR RS doesnotusethisstraig ghtforwardv validatorbutusesasepara atevalidatorf frameworkw whichresidesinthe ayer.Thismeansforexam mpleOpenMRScanreplace etheHibernat teimplement tationwitha servicesla document torientedda atabaseinthe edataaccesslayerwithoutbreakingtheserviceslay yerortheuse er 32

interfacelayerinthefuture.Alsoeachoftheimplementationscanbedevelopedinparallelsothatthe implementerscanmixandmatch,choosingthemostsuitabletechnologyforthescenarioOpenMRSis usedfor. Sothesingleresponsibilityprincipleallowsthedeveloperstoextendthesystembymixingandmatching thecorecomponentsoftheexistingsystemandreplacingsomeofthemwithcustomizedcomponents. Becauseeachoneisaseparateclosedentitywithaclearlydefinedinterfacethisisachievable.Single responsibilityprincipleimprovescohesionandhelpstocreatereusablecomponents.

Generalization
Representconceptsinsteadofspecificdetails.Whendesigninggeneralpurposesystemsthedesigner shouldabstractorconceptualizeconceptsfromthespecificfeatures.Oneoftheprincipaldesignersof thesystemexpressedthatwhenencounteringanewrequirementthemostimportantthingistofind outwhyanexistingfeaturedoesnotsupportthespecificrequirement. ForexampleinAfricancountriespeoplebelongtotribes.Scottishpeoplehaveclans.Insteadof designingatribeobjectoraclanobjectthedesignersshouldthinkaboutthehigherlevelconcepts behindtherequirement.Attheverybasiclevelitispossibletouseanentitycalledthegroupwitha configurabledisplaylabelwhichtheimplementercanchangetothetribeortheclan.OpenMRShas introducedtheconceptofpersonattributewhichisdescribedlater. Thedesigningforextensibilityisaniterativeprocess.Itisnotpossibletoforeseeaperfectdesignatthe beginning.ForexampleintheOpenMRSdatamodelatonetimethepatiententityhadatribeattribute. ThisattributewasrelevantintheinitialdayswhenthesystemwasdeployedintheAfricancountries suchasKenyaandTanzania.Buttodayitisnotrelevantwhentheprojectisdeployedinotherregions. SothetribeattributehasbeenmovedintoanattributeofthepersonentityusingtheTribemodule whichtheauthordeveloped(OpenMRSTribeModule,2008).Sotheimplementerswhoneedthetribe attributescaninstallthemoduletohavethatfeaturewhileotherswillnotbeburdenedwiththis redundantattribute.Thistribeattributeisaclearexampleofnotusingthegeneralizationprinciplethe intervieweddevelopersagreed.Thatwaswhyitwasextractedintoamoduleconsequently.

33

Thefollowingexamplesdiscussthegeneralizationprincipleusingmoreempiricalevidencefromthe systemarchitecture.Ineachofthesecasesthedatamodelisdesignedtohandlegenerichighlevel conceptsinsteadofspecificobjectsrelevanttoparticularscenarios. GeneralizingthePersonAttributes OpenMRShasthegeneralizedconceptcalledthepersonattribute.Apersoncanhavezeroormore personattributes.PersonattributesarespecificforeachOpenMRSimplementation.Implementerscan definethepersonattributesdependingonthecontext.

Figure6Personattributemodel

Apersonattributehasatypewhichcanbeabasictypesuchasastringoranintegeroritcanbea customtype.Whenusingcustomtypesthemoduledeveloperhastoprovidethelogictoloadandstore thecustomvalue.OpenMRSbasesystemprovidesthelogicforbasictypesoutofthebox. Eachpersonattributehasareadonlyviewmodeandaneditmode.Forexampleiftheuserisviewing thepatientdataOpenMRSwillshowtheattributeintheviewmode.Whentheuseriseditingtheperson attributeOpenMRSwillshowitintheeditmode.OpenMRScallstherelevantmethodsinthecustom personattributetypeinterfacetogeneratethepresentationlogicaccordingtothesituationsimilarto theLiskovssubstitutionprinciple(Martin,2000).Itistheresponsibilityofthepersonattributetypeto generatetheproperpresentationlogic.TheOpenMRSextensionpointarchitectureplugsinthe presentationlogicattherelevantplaceswherethepatientdataaredisplayedoredited. TheTribemodulemanagesthetribesofthesystem(OpenMRSTribeModule,2008).Itaddsthenew personattributetypetribe.WhentheTribemoduleisinstalleditaddsatribemanagementpagetothe administrationsectionoftheOpenMRS.Theuserswiththemanagetribespermissioncanaddnewtribe values.ThetribemodulestoresthetribesinanewtablemanagedthroughaHibernatemapping.Inthe patientdashboardthetribeisshownasastatictext.Inthepatienteditpagetheusercanselectthe tribefromthelistofexistingtribes.Thesefunctionalitiesareprovidedbythetribemodule.Thebase systemcallsthenecessarymethodsintheTribemoduletostoreandretrievethetribeobjectsusingthe 34

Liskovssubstitutionprinciple.Thebasesystemdoesnotknowaboutthehowtovieworeditthetribe objectsbutitcallsthemethodsofthepersonattributetypetotellittoshoworedititselfthroughthe interfacecontract. NamingofConcepts Aconceptcanhavemanynames.Thenamescanbesynonyms,shortnames,acronymsorinformal terms.Theconceptnamesrecordthisnomenclaturesothatthedifferentpeoplecanusedifferent namesforthesameconcept.Thesamedeceasecanbecalleddifferentnamesincludingacronyms.For examplePneumocystisPneumonia,PneumocystisCariniiPneumoniaandPCParemanynamesforthe sameconcept.Byusingmultiplenamesforthesameconceptthesystemcanmanageuniqueterms.That meansforthesystemcanpreserveasingleentitywithdifferentnamesasuniqueavoidingthe duplicates. Alsothishelpsinternationalizationandlocalization.ForexamplewhenanEnglishuserviewstheconcept itwillbeshownintheEnglishlanguagewhileaFrenchuserwillseetheconceptinFrenchlanguageif theFrenchtermfortheconceptexistsinthesystem.Thiskindofnamingsystemimprovesthe extensibility. PatientIdentifiers Differenthospitalshavedifferentpatientidentificationnumbers.Differentcountrieshavedifferent personidentificationmethods.ApersoncanhavemanypatientidentifierssuchhospitalID,social securitynumber,passportIDetc.AhospitalIDcanbedifferentineachhospitalandineachregion.They canbealphanumericornumeric.TheycanhavedifferentcheckdigitssuchasLuhnalgorithmetc.Each personidentifiercanhavedifferentvalidationcriteria.Itshouldbepossibletosearchthepatientsusing differentpatientidentifierstoo. SoOpenMRShasgeneralizedthisconceptasthepatientidentifier.Eachpatientcanhavemanypatient identifiers.AnOpenMRSimplementationcandefinetherequiredpersonidentifiersinthesystem.Ituses regularexpressionstodefineandvalidatethepatientidentifiers.Thiswaythearchitectureisnot constrictedtosomepredefinedidentifiers. TheabovesectionshavediscussedtheobservationsongeneralizationprincipleintheOpenMRS architecture.Howtodesigngeneralizationintoarchitectureisachallengeandthedesignersshouldput alotofeffortandthoughtintothis.

35


KeyValueDataModel
ThisisthemostpowerfulextensibilityprincipleusedintheOpenMRSarchitecture.Thisisawidelyused techniqueinenterpriseapplicationstodaytosupportfuturerequirements.Thekeyvaluedatamodelis explainedindetailbelow. TheOpenMRShasanextensibleandflexibledatamodel.Inaconventionalmedicalrecordsystemthe patientdatacanbestoredasfollows. Date Patient Creatinine (units/L) 1/6/2010 8/6/2010 JohnDoe JohnDoe 174 170 110 100 Glucose(mg/dL)

Table1Statictablestructuretorecordpatientdata

CreatinineandGlucosearedifferentdataelementsstoredagainsteachpatient.Theycanberecorded forapatientineachdoctorvisitsothattherecanbealistofentriesforeachpatientovertime.Thisisa fastandefficientmodeltostorethepatientdata. ButifthereisanewrequirementtorecordanewdataelementsuchasPlateletcountorPotassiumlevel ofapatientthenthetablestructurehastobemodifiedtohandlethenewrequirement.Forexamplein thatcaseanewcolumnhastobeaddedforthePlateletcount.Thedatastructurecannotbedesigned tohandleeveryforeseeabledatarequirementinthebeginning.Evenifitispossibleitwouldwaste storagespace. AlsothereisthequestionwhatifthelabchangesthemeasurementunitofCreatininefromunits/Lto units/ml.Inthatcaseeithertheexistingvalueshavetobeconvertedtothenewunitoranewcolumn hastobeaddedforthenewmeasurement.Sothisdatastructureisrigidandinflexible. Date 1/6/2010 8/6/2010 Patient JohnDoe JohnDoe Column1 174 170 Column2 110 100 Column3 160

Table2Genericcolumnstorecordpatientdata

36

Analternativeapproachtosolvethisproblemistohaveanumberofgenericcolumnsbuiltintothe systemattheinitialdesignstageasinthetableabove.Forexamplemanybusinesssystemshaveasetof columnsnamedsuchascolumn1,column2etc.Atthebeginningwhenimplementingthesystemthe usergroupwillagreethatthecolumn1willstoreCreatinine(mg/L)level,column2willstoreGlucose (mg/dL)etc.Thisapproachhasmanyshortcomings.Itwastesstoragespaceaswellascreatesalimiton thenumberofdataelementsthatcanbestored. Alsousinggenericcolumnsforcestheusertointerpretwhateachcolumnstores.Somebusiness systemsprovideconfigurablelabelssothatthecolumn1willbedisplayedintheuserinterfaceas Creatinineasshowninthetablebelow. Column Column1 Column2 Column3
Table3Givinglabelsintheuserinterfacelevel

Label Creatinine
Potassium

Thiswayusercangivenamestothedatafieldswhenpresentingittotheuserasshowninthefigure below. VisitDate PatientName Column1Creatinine

Column2 Potassium

1/6/2010 JohnDoe 174 170

Figure7Presentingpatientdatainagenericcolumnsystem

KeyvaluedatamodelusedinOpenMRSisextensibleandsolvesmanyoftheaboveproblems.Inthis caseinsteadofacolumnarmodelthedataarestoredinstackedrows.Eachrowrecordsavaluefora specificpatientobservationasshowninthetablebelow.OpenMRSrecordsthekeyandvalueelements fromasetofcodedvaluescalledconceptsasdescribedlater.Theconceptdictionaryisthemetadata abouttheconcepts. Date 1/6/2010 1/6/2010 Patient JohnDoe JohnDoe Key Creatinine Glucose Value 174 110

37

8/6/2010 8/6/2010
Table4Keyvaluedatamodel

JohnDoe JohnDoe

Creatinine Glucose

170 100

InOpenMRSthiskeyvaluemodelismappedtorelationaltables.Butdocumentorienteddatabaseshave becomepopularintherecenttimes.Thesearchengineindexesusethisdesignheavily.The BigTable(Chang,etal.,2006)developedbyGoogleandApacheHadoop(White,2009)usedbyYahooare somenotableexamples.Thiskeyvaluemodelmapsintodocumentorienteddatabasedesigns seamlessly. OpenMRSDataModel TheOpenMRSusesthiskeyvaluedatamodeltorecordthemedicalinformation.Thesedomainobjects supportdiversescenariosrelatedtohealthcare.Thefollowingparagraphsdescribesomedomain entitiesinbrieftoshowhowthiskeyvaluedatamodelhasbeenusedinthesystem. AconceptisaclearlydefinedtermorideaintheOpenMRSsystem.Forexamplethequestionbloodtype andtherelatedanswersA,B,ABandOareallseparateconcepts.Theyarecodeddatapoints.Each conceptsuchasbloodtypeorbloodtypeAhasaclearlydefinedmeaningandsemantics.Intheinitial OpenMRSdesigndiscussionstheideaofconceptwasnamedterm.Thecollectionofconceptsiscalled theconceptdictionary.Whenimplementingamedicalrecordsystem,thesystemimplementerdefines theseconceptsfirstaccordingtothemedicalscenario. TherecanbebillionsofvalidconceptsintheworldbuteachOpenMRSimplementationdefineswhatis requiredforthecurrentimplementationwhetheritisanAIDSclinicorapediatricunit.Sotherecanbe manyconceptsdefinedinmanyOpenMRSimplementationsforthesameideaofbloodtypeAbutonlya singleconceptineachimplementation.OCCinitiativeisworkingonconceptinteroperabilityservices betweendifferentOpenMRSimplementations(OpenMRSConceptCooperative,2010).Theconcept proposalmoduledevelopsanapprovalworkflowtoletthedataentrypersonneltoproposenew concepts(OpenMRSConceptProposalModule,2010). Anencounterisatypicalinteractionbetweenthepatientandtheprovider.Theprovidercanbea doctor,anurseorfieldworker.Forexampleadoctorvisit,ahomevisitoratelephoneconversationisan encounter.

38

Anencounterconsistsofobservations.Observationsarethequestionandanswerpairs.Theycanbe observations,measurements,testresultswhicharerecordedagainstapatient.Forexampleforthe questionwhatistheweightconcepttheansweristhenumeric8kg,whatisthebloodtypeconcepthas theanswerconceptAB. Soobservationsarerecordedusingconcepts.Theobservationquestionisaconceptsuchastheblood typeorthebloodpressure.Theanswercouldbeaconceptfromaprespecifiedsetofconceptssuchas bloodtypeA,oranumericvalueetc. ThesegenericentitiesarenotspecifictoaclinicservingAIDSpatientsoradentistryorapediatricward. Bydefiningtheconceptsaspecificimplementationcanbuildtheircustomextendedsolution.OpenMRS DataModel,2010describesthedatamodelfurther. Sothekeyvaluedatamodelisapowerfulprinciplethatcanbeappliedforextensibilityinarchitecture. Oneweaknesscomparedtoconventionalcolumnardatastructuresisthatthekeyvaluedatamodelcan belessperformant.Buttheimprovementsinthehardwareperformanceandtheuseofdocument orienteddatabasescanovercomethissignificantly.

LeverageandReuseExistingTools
Reusingexistingfunctionalityimprovesthequalityofthecodeandtheproductivityofthedeveloper. Developersshouldalwaystrytoleveragetheexistingfunctionalityinsteadofreinventingthewheel. Hunt&Thomas,1999says"Everypieceofknowledgemusthaveasingle,unambiguous,authoritative representationwithinasystem."Doingthesametaskindifferentwaysindifferentplacesintroduces newbugsandmakingchangesisdifficultbecausethechangesarenotminimizedtoaspecificregion.But itisimportanttogobeyondandreusehighlevelcomponentwiseelementstoimproveextensibility. Thefollowingexamplesfurtherexplaintheidea. OpenMRShasleveragedtheHibernatemappingsandSpringbeanstoallowmodulestosupport persistenceandbusinesslogicservicesrespectivelyinsteadofdevelopingtheirowncustommechanism. Reusingexistingfunctionalityhastheadvantageofminimizingthelearningcurveofthedeveloperwhen usingthetechnology.Alsoitishardtodesignasystemfromthegroundupthatisequivalenttothetried andtestedtechnologiessuchasSpringandHibernatefeaturesinfunctionalityandperformance.The followingthreesectionswillexplainsomeoftheseobservations. 39

ExtendingthePersistenceLayer ThepersistencelayerofOpenMRSconsistsofadataaccessobjectlayerandanimplementationin Hibernate.ThepersistencelayerofOpenMRScanbeextendedinseveralways.InthesecasesOpenMRS leveragesthefunctionalitysupportedbytheSpringframeworkandHibernate.Thismakesiteasierfor themoduledevelopersbecausetheycanusetheexistingknowledgeaboutHibernatetoaddnewdata structurestoOpenMRS.

OpenMRSUser Interface

OpenMRSServices Layer

ModuleServices

OpenMRSDatabase

ModuleData Mappings

Figure8Extendingthepersistencelayerandserviceslayer

AnOpenMRSmodulecandefinenewHibernatemappingsandtheycanreferencetheexistingHibernate mappingsinthebasesystem.OnmodulestartupOpenMRSreadsthecustommappingsgiveninthe moduleandloadsthemupintothecoreHibernateconfiguration.

40


Figure9Modulesreferencingcoredomainobjects

ExtendingServices SimilartothepersistencelayerOpenMRSdevelopershaveleveragedtheSpringframeworkbeansto definenewservicesinthemodules.ModuledeveloperswritetypicalSpringbeansinthemodule configurationfile.Seetheappendixmoduleapplicationcontextfile.OnmodulestartupOpenMRSreads theseelementsandloadstheSpringbeansintotheapplicationcontextdynamically.Inthiscasethecore systemhasreusedtheSpringframeworkservicedefinitionforextensions. DataMigrationandUpgrade Anotherobservationtoprovethisdesignprinciplecanbetakenfromthedatamigrationmechanism.For everynewversionofOpenMRSorthemodulesthedatabasemustbeupgradedwithnewtables, columnsordata.SomesystemsreleaseaseparateSQLscriptwiththeversionsothattheusercanrun themasaseparatestep.Butmodernapplicationshaveintegratedthatstepautomaticallyintothe releaseitself.TheearlierOpenMRSversionshadaninhousebuiltupgrademechanismwherethe appropriateSQLstatementswererunaccordingtothecurrentversion.Butthishasshortcomingsand limitations.TherearededicateddatabaseupgradelibrariessuchasLiquibase(LiquiBase,2010).Sothe 41

OpenMRScoredevelopershavereplacedtheexistinglimitedmechanismwiththislibrary.Becauseitis alsoopensourceithasbeenintegratedatthecodelevelsothatitispartofthecoresystem.Thishas theadvantageoftakingfullfunctionalityofadedicateddatabaseupgrademechanismaswellasletting developersusethewelldocumentedLiquibaseupgradescriptformattowritetheirupgradescripts. Soasevidentfromtheseexamplescombiningandreusingexistingextensiblecomponentsisavery powerfulmechanisminimprovingtheextensibilityofsystemarchitecture.

UserCenteredDesignandPublicDesignProcess
Thisdesignprincipleisahumanfactorprinciple.Byinvolvingtheuserinthedesignprocessitispossible tomakesurethatthefinaloutcomeisgoingtobeusefultotheusercommunity.Thenewfunctionality shouldcatertotherealliferequirements. AccordingtotheintervieweesOpenMRSpracticestheconceptofinvolvingrealusersintheroleof championsinthedevelopmentprocesswhendevelopingnewfunctionality.Thisinsuresthatthefeature isgoingtobeusedinreallifeandwillnotbecomejustanotherfeaturethatisnotgoingtobeusedor doesnotdowhattheusersrequireinreallife.Thechampionsareinvolvedinthefulldurationto validatetheoutcomeofthedevelopment.AccordingtothekeydevelopersoftheOpenMRSprojectit hasbeenagreedthatallfuturedevelopmentsarebasedonreallifeusecaseswithachampionfromthe usercommunity. AnotherimportantfactelicitedfromtheinterviewsisthatthemostoftheOpenMRSdevelopersgoto theimplementationsitesfrequentlyandhelpimplementthesystemsinAfricaandSouthAmerica. Accordingtothedevelopersthisnotonlyimprovestheunderstandingoftheuserrequirementswellit alsogivestheopportunitytotraintheindividualsintheimplementationsitesonhowtodeveloptheir ownextensionsoralterthesystemtosupporttheirspecificneeds.AccordingtotheOpenMRS developerswiththecloseinvolvementoftheuserstheOpenMRSdesignerscanseethedifferentfuture requirementsandtheirvariationsthatneedtobehandledbythesystem.Otherwisewithoutseeingthe bigpicturedesignerswillonlygivesolutionsthatsatisfyanarrowsegmentoftheusers. AstudyconductedinOpenEMR,anotheropensourceelectronicmedicalrecordsystem,withthegoalof understandinghowtherequirementsareelicitedinsmallscaleopensourcesoftwareprojectsshows thatthemajorityofthefeaturesareassertedbythedevelopersbasedoneithertheirpersonal 42

experienceortheirknowledgeoftheuserneeds.Relativelyfewwererequesteddirectlybythenon technicalusers(Noll&Liu,2010).ThisobservationisalsotrueaboutOpenMRS.Mostofthekey designersandleadersofOpenMRSarealsomedicaldoctorsinpracticeorareinvolvedinthe administrationofthefieldofhealthcare.Sothereisacloseconnectionbetweenthedeveloperandthe user.Fromtheauthorspersonalexperiencecommercialsoftwareprojectslackthiscloseintegration. ByusingapublicdesignprocesstheOpenMRSdesignerscanaggregatetherequirementsofalltheusers andcomeupwithsolutionsthatcanhandleneedsofeverybodywithoutconstantlyredesigningthe systemfromversiontoversion.OpenMRSdevelopersholdweeklydesignreviewmeetingsconnecting developersfromallovertheworld.Anyinterestedpartycanjointhesemeetingsandexpresstheirviews andalterthepathofnewdesigndecisions. Insummarythehumanfactorprinciple,usercentereddesignandpublicdesignprocessgivesthe designerabroaderviewoftheuserneedssothedesigncanhandlediversebutrealrequirements.

InternalizationfromInception
Animportantdesignprincipleistothinkabouthowtodesignforinternationalizationandlocalization fromtheverybeginning.Thisisanextensionfromthegeneralizationprinciple.Mostoftheapplications arefirstdesignedanddevelopedwithoutthinkingaboutinternationalizationandlocalization,andthen theyarepatchedtohandletheinternationalaudienceasdeficienciesareexposedbytheusers. Sometimesthesechangescanimpacttheoverallarchitectureandneedsystemwidechanges.Ithas beenseeninrecenttimesthatsomeprojectsinApachehavegonebeyondinternationalizationinthe userleveltoeventhedeveloperlevelwhereevenlogoutputsanddebugmessagesare internationalized. OpenMRSdatamodelabstractsthenamingofconceptssothatoneconceptcanhavemanynames includingsynonyms,acronyms,shortnamesandeachoneindifferentlocales.Sointernationalizationis designedfromthedatamodellevel.Accordingtotheintervieweesrecentdevelopmentworkhad startedtofindandfixtheremainingdeficienciesinthisareasuchasinOpenMRSlocalizationtools project(OpenMRSLocalizationTools,2010). ItissaidthatOpenMRShasimplementationsthatweredevelopedandruninnonEnglishlanguages entirelysuchasFrenchandSpanishinsomeAfricanandSouthAmericancountries.ButOpenMRShas 43

notbeenusedinenvironmentswithlanguagessuchasChineseJapaneseKorean(CJK)orArabic.Asthese languageshavelargecharactersetsandhavesignificantdifferencesfromtheotherlanguagessuchas Arabicwrittenfromrighttoleft,itisimportanttodesignthesystemwithsomeoftheselanguagesin mind. Onecouldarguethatinternationalizationisnotrelevanttoextensibility.Butsomeofthecomplex issuesfacedbythedeveloperslaterinthedevelopmentlifecycleinhandlingnewuserrequirementsare relatedtosupportingusersfromdifferentlocales.Mostenterpriseapplicationsaredevelopedforonly USEnglishlocaleatthestart.AsthecustomerbaseincreasestheapplicationissoldtoFrench,Spanish, Chinese,Arabicandotherlanguagespeakingusers.Theseusersrequiretheuserinterfacetosupport theirnativelanguages,dateformatsandnumberformats.Fromtheauthorsexperienceitisevident thattheserequirementscreatetimeconsumingandcostlysystemwideredesignandcodechanges.A commonissuethattheauthorhasexperiencedatworkistheissueofswappedmeaningoftheperiod andthecommainEnglishandScandinavianlocales.Iftheapplicationisnotkeptopenfortheseneeds fromthestartthefixesareverydifficulttoimplement.Soitisimperativethattheinternalizationis handledfromthebeginningtocreateanextensiblearchitecturethatcouldsupportnewrequirements ofhandlingdifferentlocales. Insummarythedesignprinciple,consideringinternationalizationfromthestartoftheprojectimproves theextensibilityofthearchitecturetosupportdiverseuserneedsandpreventscostlysystemwide changeslater.

PrincipleofUsingMetaphor
Usingconceptsandbehaviorwhicharefamiliartotheuseristheprincipleofmetaphor.Forexamplein designingtheuserinterfaceformusicplayersthedesignersusethesameplay,pauseandstopbuttons availableinaphysicaltaperecorder.Thiswaytheuserwillknowhowtooperatethesoftwarewithout furtherinstructions.Theuserwillknowthatclickingthepausebuttonwilllettheusercontinuefromthe pausedlocation.Ontheotherhandifthebehaviorisdifferentfromwhatisexpectedthentheuserwill getconfused.

44

ThefollowingsectionswilldescribetwoinstanceswheretheprincipleofmetaphorisusedinOpenMRS. UsingthecommonknowledgefamiliartothedevelopersOpenMRShasreducedthelearningcurveof developersintheextensiondevelopment. ServletsandFilters JavadevelopersarefamiliarwithJavaservletsandfilters.OpenMRSprovidesaServletandFilter interfaceforthemodulesdevelopers.Themoduledeveloperscanwriteservletsandfilters implementingthesameinterfacesasintheJavaServletandFilterspecifications.Onmodulestartupthe basesystemreadsthemoduleconfigurationandregistersthemoduleservletsandfiltersinacustom OpenMRSservletandafilter. Whenrequestsarereceivedforthemodulecontextpaththiscustomservletandfiltercallsthespecific moduleservletorfilterpassingthearguments.Thatmeansthesemoduleservletandfiltersarenot livingintheJavaServletcontainerbuttheOpenMRScustomservletandfiltersimulatesthe environmentforthem. BecausethesearenotrealJavaservletsandfilterswhenthemoduledeveloperstrytouseadvanced servicesprovidedbyServletandFilterspecificationtheygeterroneousresults.Thisisamajor disadvantageofthisapproach.Accordingtotheinterviewsthemoduledevelopersfaceddifficultiesin assumingthemetaphorasarealServletinstance.

OpenMRSServlet

Module Module Servlet Servlet

Figure10OpenMRScustomservletdirectingrequeststomoduleservlets

Portlets SimilartoServletsandFilters,OpenMRShasimplementedtheportletmechanisminthebasesystem. Theseportletsarepluggedintothebasesystemthroughextensionpointsdefinedintheuserinterface. Theportletinterfacesplugsintothedefaultwebuserinterfaceseamlesslyatselectedextensionpoints inthebaseuserinterface.Thecombinationgivesaunifieduserinterfacetotheuser.

45

PortletContainer

CoreUI

ModuleUI

CoreServices

ModuleServices

CoreDatabase

ModuleData Mappings

Figure11Extendingasaportalcontainer

Whenusingmetaphoritisimportanttoconsiderhowmuchfurtheritissimulated.Metaphorthat simulatepartiallycouldfrustratetheextensiondeveloperbecausethedeveloperhasacertain preconceptionofhowtheextensionwouldwork.Whenitdeviatesfromthenormalbehaviorit frustratesthedeveloper.Soitisimportanttodocumentthecapabilitiesandthelimitationsofthe extensionmetaphorscomprehensively. Insummarythehumanfactorprinciple,usingmetaphorsinthearchitectureimprovesthe understandabilityandmodifiabilityfortheextensiondeveloperandtheuserwhichwillimprovethe extensibilityofthesystem.

UseofStandards
Therearewellestablishedstandardsandprotocolsinusetodayfordatainput,output,transmission, storageetc.Oneapproachtomakingasystemextensibleisbyusingstandards.Forexamplebyusing XMLorCSVfordatainputandoutputwecanachievebetterinteroperability.Theinterviewsandthe systeminvestigationrevealedmanystandardsusedbytheOpenMRSarchitecturesuchasHL7,XMLetc. 46

Theuseofstandardshasthreeadvantages.Thefirstoneisthatthemoduledevelopersandusersareall familiarwiththemandtheirlearningcurveisminimal.Secondlystandardsaredevelopedbya communityoverconsiderabletimeandreinventingthemispronetoerrororwillmissimportant featuresacquiredoveryearsofcommunityexperience.Thirdlyusingstandardsthesysteminherently becomesextensibleattheinterfaceboundaries. ForexampleHL7isanOSIapplicationlayernetworkprotocoltosupporttheinterchangeofmedical informationamongawidevarietyofmedicalapplicationsanddevices(Whitson,2009).OpenMRSuses thisformatforpatientdataentryintothesystem.ByexposingtheHL7attheinterfaceboundary moduledeveloperscanseamlesslyconnectandinterchangewithothermedicalrecordsystemswithless effortfromthemoduledeveloperspointofview.Accordingtothesysteminvestigationandinterviews thepatientdataenteredthroughtheformsaresavedinthesystemasXML.TheseXMLformsare convertedintoHL7format.AseparatescheduledprocessreadstheseHL7documentsandinsertsthe patientdataintothesystem.SoaninteroperableextensioncanreadHL7datafromanexternalsystem anddirectlyinsertHL7documentsintothesystem.Thiswayusingstandardsimprovestheextensibility oftheoverallarchitectureimplicitlywithoutfurtherwork. Insummarythedesignprinciple,useofstandardshelpstheextensiondeveloperreuseexisting knowledgeandtheexistingtoolstodevelopextensiblesolutions.

SecurityfromInception
Thelastdesignprincipleformulatedfromtheresearchisdesigningsecurityfromtheinceptionofthe development.AsdescribedinthelimitationsintheOpenMRSmodulearchitecturesecuritydesignhas beenaninadequatelyimplementedissue.Twotypesofsecuritywerediscussedinthatsection.Thatis, 1. Usersecurityuserauthenticationandauthorization 2. Modulesecurityhowcananinstalledmoduleisauthenticatedandwhatcananinstalled moduleisauthorizedtoperform OpenMRSarchitectureincludesarobustusersecuritymechanismusingrolesandprivilegessetas describedinthemodulelimitationssection.Evenmodulescanaddnewprivilegessothatonlyusers withspecificprivilegescanperformthemodulerelatedfunctions.ButOpenMRSarchitecturedoesnot includeamodulelevelsecuritymechanism.Forexamplethecoresystemcannotverifytheauthorof 47

amoduleandrestrictaccesstothepatientdataforthatmodule.Afterinstallingamodule,ithasfull privilegestoperformanyfunctioninthesystemalthoughthereisauserprivilegethatrestrictwhich userscaninstallmodulesinthesystem.ForOpenMRSuserrequirementsthiswasacceptableaccording tothecoredevelopers. Whendesigningextensiblesystemssecuritydesignisanimportantconsiderationfromthestart.How muchsecurityshouldbeimplementeddependsonthesystem.Butitisdifficultintroduceormodifythe securitymechanismafterthesystemhasbeenreleasedtothewideruserbase.Intervieweesagreethat itcouldbreakthebehaviorofalltheextensionsthatweredevelopedpriortoanewsecuritydesign. Modulelevelsecuritycanbeenforcedbyusingacodesigningmechanism.Allmatureplatformsprovide supportforthat.ForexampleJavaplatformprovidesJARsigningmechanisms(Sun,2010)while.NET platformprovidessigningassemblywithastrongnamefeature(Microsoft,2010). Whendesigningforsecurityfrominceptionthereareseveralpointstoconsiderintheweblayerofa system.Therearemanyvulnerabilitieswebsitesfacesuchascrosssitescripting,crosssiterequest forgery,scriptinjection(OWASP,2010).Itisimportanttodesignsecuritymechanismsand recommendationsinthecorearchitecturefromtheoutsettothwartthesevulnerabilitiesasfeatures andbestpractices.Forexamplecoredesignersshouldincludethelibrariesandtoolsthatinhibitcross sitescriptingincodeandspecifytheirusageasbestpracticesorrecommendations.Althoughthe OpenMRSarchitectureusescodelibrariesthatsecureagainstthesewebsecurityvulnerabilitiesthe investigationfoundoutthattheirusageisnotconsistent,especiallyinthemodulecode.Accordingto theinterviewswiththecoredevelopersandthemoduledeveloperstherearenobestpractices, recommendationsorchecklistsspecifiedaboutthewebsecurity.Thisisashortcominginthesystem. Implementingsystemwidewebsecuritymechanismslateriscostly,timeconsumingandwillaffect systemwidechanges.Soanextensiblesystemshouldconsidersecuritydesignfromtheinception.

48

ConclusionandFutureWork
Astheresultofthisresearchprojectthisdissertationhasformulatedseveralimportanttechnicaland humanfactordesignprinciplesthatasystemcanincorporatetoimproveextensibility.Thoseare summarizedbelow. Aspectorienteddesign Usingaspectorientedprogrammingtoaugment,extendoroverridethesystembehavior.So thatthecorearchitectureiskeptclosedbutextendedthroughtheaspectoriented programmingmechanisms. Singleresponsibilityprinciple Eachclass,unit,moduleorlayershouldhaveonlyoneresponsibilitytofacilitatereuseand swappingabilityandtoavoidtherippleeffectthroughoutthesystemandthefrictionof change. Generalization Representconceptsinsteadofspecificdetails.Analyzeanddesignforoverallrequirements andproposegenericsolutions. Keyvaluedatamodel Useextensibleandflexiblekeyvaluedatamodeltokeepspaceforfuturerequirements. Leverageandreuseexistingtools Reuseexistingfeatures,tools,librariesandframeworkstoimprovethequalityofthesystem andtheproductivityofthedeveloperinsteadofreinventingthewheel. Usercentereddesignandpublicdesignprocess Involvetheusersinthedesignprocessfromthestarttodrivethedevelopmentasa championandhaveapublicdesignprocesstoreviewthedesignagainstfuture requirements. Internalizationfrominception 49

Analyzeanddesignforinternationalizationandlocalizationfromthebeginningtoavoid futuresystemwidechangeswhenenhancingthesystemfornewuserrequirements. Principleofusingmetaphor Usingconcepts,behavior,structuresandmodelswhicharefamiliartotheuserandthe developertominimizeconfusionandlessenthelearningcurve. Useofstandards Usewellestablishedstandardsandprotocolsfordatainput,output,transmissionand storagetoimproveinteroperabilityandhandlingnewrequirementsimplicitly. Securityfrominception Designforsecurityfromthestartofthedesignandestablishthenecessarycontrolsand behaviortoavoidsystemwidechangeslater. Theeffectivenessofthesedesignprincipleshavebeendiscussedbytheusecasesfromtheopensource medicalrecordsystem.Itisevidentfromtheseexamplesthatthedesignprincipleslistedarekeyfactors inimprovingtheextensibilityofasystemandtoavoidsystemwidemodificationlater.Althoughthe principlesarenotspecifictomedicalrecordsystemsfurtherresearchmustbecarriedouttofindout whetherthesedesignprinciplesarerelevanttootherinformationsystems. Currentlytheauthorworksindevelopingthenextgenerationsoftwareasaservice(SaaS)platformfor logistics,procurementandtravelmanagementapplicationsatasoftwaredevelopmentorganization. Theaimistobuildleancorearchitecturewithpluggablefeaturesthatuserscanmixandmatchor developerscanwriteapplicationseasilytointegrateandinteractwiththeexistingfeatures.Itisevident thatthesedesignprinciplesarerelevantinthiscontexttoo.Itisalsoevidentthatitisdifficulttocome upwithanarchitecturethatcansupportextensibilitywell. Therewereseveralprototypedesignsthatwerediscardedoverthelastfewmonthsbecausetheydid notsupporttherequiredextensibilityrequirements.Twoofthemajorissuesintheprototypeswerethe lackofdeveloperproductivityandtroubleshootingsupport.Someofthereasonsfortheshortcomings werenotusingestablishedstandards,notusingclearmetaphorsandtryingtoreinventthefunctions insteadofusingtheexistingtoolsandtechnologies.Intheoldplatformnotconsideringthe

50

internationalizationaspectsfromtheinceptionhasbeenamajorweakness.Thishasincreasedthecost offixingtheissuesthathasemergedlaterinthemaintenancelifecyclewithsystemwidechangesto facilitatethefunctionalityofChineseandArabicusers.Iftheidentifiedprinciplesareincorporatedinto systemarchitecturefromtheinceptionthedesignerscanmakecertainthatthesystemsareextensible andwillwithstandthefuturerequirementswithoutsystemwidechangesasshownfromtheevidencein theOpenMRSarchitecture. Thenextstepoftheresearchwouldbetoinvestigatethescalabilityandperformancewhenapplying thesedesignprinciples.Generalizationofconceptsandthekeyvaluemodelcoulddecreasethe performanceofthesystemsignificantlycomparedtostaticcolumnardatamodels.Whenprocessing hugepatientsetsithasbeentoldthatthekeyvaluemodelbackedbytherelationaldatabaseslows downtheprocesses.TocounteractthatOpenMRSdevelopersexportthedataintoflatdatastructures firstandprocessthemseparately.Butthiscouldbeovercomewiththeintroductionofadocument orienteddatabasewhichstoresthedataaskeyvaluepairsinherently. Inconclusionthisresearchprojecthasformulatedthekeytechnicalandhumanfactordesignprinciples relevanttoextensibilityinthearchitectureoftheOpenMRSmedicalrecordsystem.Itishopedthat thesethemeswillfillagapintheknowledgeofdesigningsoftwarearchitectureforextensibility.

51

Bibliography
Allen,E.(2001).DiagnosingJavaCode:Designingextensibleapplications,Part1.Retrievedfrom developerWorks:http://www.ibm.com/developerworks/java/library/jdiag0925/index.html Annas,G.J.(2003).HIPAARegulationsANewEraofMedicalRecordPrivacy?NewEnglandJournalof Medicine. Anokwa,Y.,Hartung,C.,Brunette,W.,Borriello,G.,&Lerer,A.(2009).OpenSourceDataCollectionin theDevelopingWorld.IEEEComputer. Chang,F.,Dean,J.,Ghemawat,S.,Hsieh,W.C.,Wallach,D.A.,Burrows,M.,etal.(2006).Bigtable:A DistributedStorageSystemforStructuredData.SeventhSymposiumonOperatingSystems DesignandImplementation. Clayberg,E.,&Rubel,D.(2006).Eclipse:BuildingCommercialQualityPlugins.AddisonWesley Professional. EMRExperts.(2010).RetrievedfromEMRExperts:http://www.emrexperts.com/ Fraser,H.S.,Biondich,P.,Moodley,D.,Choi,S.,Mamlin,B.W.,&Szolovits,P.(2005).Implementing electronicmedicalrecordsystemsindevelopingcountries.InformaticsinPrimaryCare. Gamma,E.,Helm,R.,Johnson,R.,&Vlissides,J.(1994).DesignPatterns:ElementsofReusableObject OrientedSoftware.AddisonWesleyProfessional. Gill,J.,&Johnson,P.(2002).ResearchMethodsforManagers.SagePublications. Hannan,T.,Rotich,J.,&Odero,W.(2000).TheMosoriotmedicalrecordsystem:designandinitial implementationofanoutpatientelectronicrecordsysteminruralKenya.InternationalJournal ofMedicalInformatics. Hunt,A.,&Thomas,D.(1999).ThePragmaticProgrammer:FromJourneymantoMaster.Addison WesleyProfessional. Kelly,A.(2002,August).ThePhilosophyofExtensibleSoftware.ACCUOverloadJournal. LiquiBase.(2010).LiquiBaseManual.Retrievedfromhttp://www.liquibase.org/manual/home

52

Liskov,B.(1987).DataAbstractionandHierarchy.ConferenceonObjectOrientedProgrammingSystems LanguagesandApplications. Lober,W.B.,Wagner,S.,&Quiles,C.(2010,January).Developmentandimplementationofaloosely coupled,multisite,networkedandreplicatedelectronicmedicalrecordinHaiti.ACMSIGOPS OperatingSystemsReview. Mamlin,B.W.,Biondich,P.G.,Wolfe,B.A.,Fraser,H.,Jazayeri,D.,Allen,C.,etal.(2006).Cookingupan opensourceEMRfordevelopingcountries:OpenMRSarecipeforsuccessfulcollaboration. AMIAAnnualSymposiumProceedings. Martin,R.C.(1996).TheOpenClosedPrinciple.C++Report. Martin,R.C.(2000).DesignPrinciplesandDesignPatterns.ObjectMentorInc. Martin,R.C.(2002).AgileSoftwareDevelopment,Principles,Patterns,andPractices.PrenticeHall. McIlroy,M.D.,Pinson,E.N.,&Tague,B.A.(1978).UnixTimeSharingSystemForward.TheBellSystem TechnicalJournal. MediNotes.(2010).RetrievedfromMediNotes:http://www.medinotes.com/ Meyer,B.(1988).ObjectOrientedSoftwareConstruction.PrenticeHall. Microsoft.(2010).SigninganAssemblywithaStrongName.Retrievedfrom http://msdn.microsoft.com/enus/library/xc31ft41%28v=vs.71%29.aspx Noll,J.,&Liu,W.M.(2010).Requirementselicitationinopensourcesoftwaredevelopment:acase study.Proceedingsofthe3rdInternationalWorkshoponEmergingTrendsinFree/Libre/Open SourceSoftwareResearchandDevelopment. OpenEMR.(2010).RetrievedfromOpenEMR:http://www.oemr.org/ OpenMRSAccessLoggingModule.(2009).RetrievedfromOpenMRS: http://openmrs.org/wiki/Access_Logging_module OpenMRSBIRTReportModule.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/BIRT_Report_Module_User_Guide

53

OpenMRSConceptCooperative.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/WorkingGroup/OCC OpenMRSConceptProposalModule.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Concept_Proposal_Module OpenMRSDataModel.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/OpenMRS_data_model OpenMRSDocumentation.(2010).RetrievedfromOpenMRS:http://openmrs.org/wiki/Documentation OpenMRSIDGenerationModule.(2008).RetrievedfromOpenMRS: http://openmrs.org/wiki/Idgen_Module OpenMRSImplementations.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Implementations OpenMRSLocalizationTools.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Localization_Tools OpenMRSModuleRepository.(2010).RetrievedfromOpenMRS: https://modules.openmrs.org/modules/ OpenMRSRolebasedHomepageModule.(2008).RetrievedfromOpenMRS: http://openmrs.org/wiki/Role_Based_Homepage_Module OpenMRSSOAPWebServicesModule.(2009).RetrievedfromOpenMRS: http://openmrs.org/wiki/SOAP_Web_Services OpenMRSSourceCode.(2010).RetrievedfromOpenMRS:http://dev.openmrs.org/browser OpenMRSSqldiff.(2008).RetrievedfromOpenMRSSqldiff: http://openmrs.org/wiki/Module_sqldiff_File OpenMRSSyncModule.(2010).RetrievedfromOpenMRS:http://openmrs.org/wiki/Sync_Module OpenMRSTribeModule.(2008).RetrievedfromOpenMRS:http://openmrs.org/wiki/Tribe_Module

54

OWASP.(2010).OWASPTopTenProject.Retrievedfrom http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project PRAXIS.(2010).RetrievedfromPRAXIS:http://www.informed.com/ Ramsdale,C.(2010).LargescaleapplicationdevelopmentandMVP.RetrievedfromGoogleWebToolkit: http://code.google.com/webtoolkit/articles/mvparchitecture.html Rotich,J.,Hannan,T.,&Smith,F.(2003,July).InstallingandImplementingaComputerbasedPatient RecordSysteminSubSaharanAfrica:TheMosoriotMedicalRecordSystem.Journalofthe AmericanMedicalInformaticsAssociation. Rudestam,K.E.,&Newton,R.R.(2001).SurvivingYourDissertation:AComprehensiveGuidetoContent andProcess.SagePublications. Rugaber,S.,Ornburn,S.B.,&LeBlanc,R.J.(1990,January).RecognizingDesignDecisionsinPrograms. IEEESoftware. Stylos,J.,&Myers,B.(2007).MappingtheSpaceofAPIDesignDecisions.SymposiumonVisual LanguagesandHumanCentricComputing.IEEE. Sun.(2010).SigningCodeandGrantingItPermissions.Retrievedfrom http://download.oracle.com/javase/tutorial/security/toolsign/index.html Tavares,A.L.,&Valente,M.T.(2008,September).AgentleintroductiontoOSGi.ACMSIGSOFT SoftwareEngineeringNotes. Trujillo,S.,Azanza,M.,Daz,O.,Capilla,R.,&Sebastian,S.(2007).ExploringExtensibilityofArchitectural Design.WorkshoponSharingandReusingArchitecturalKnowledge.IEEE. VistA.(2010).RetrievedfromVistA:http://vistapedia.net/index.php?title=Main_Page WeberJahnke,J.H.,&Price,M.(2007).EngineeringMedicalInformationSystems:Architecture,Data andUsability&Security.29thInternationalConferenceonSoftwareEngineering,IEEE. White,T.(2009).Hadoop:TheDefinitiveGuide.O'ReillyMedia. Whitson,G.(2009).HealthLevelSeven:TheCornerstoneofMedicalInformatics.JournalofComputing SciencesinColleges. 55

Wilson,G.,&Oram,A.(2007).BeautifulCode.O'ReillyMedia. Wolfe,B.A.,Mamlin,B.W.,Biondich,P.G.,Fraser,H.S.,Jazayeri,D.,Allen,C.,etal.(2006).The OpenMRSsystem:collaboratingtowardanopensourceEMRfordevelopingcountries.AMIA AnnualSymposiumProceedings. Wolfinger,R.(2008).PluginArchitectureandDesignGuidelines.OOPSLA. Yourdon,E.(2006).JustEnoughStructuredAnalysis. Zenger,M.(2004).ProgrammingLanguageAbstractionsforExtensibleSoftwareComponents.Swiss FederalInstituteofTechnology,Lausanne,Switzerland.

56

AppendixAProjectPlan
Task Researchproposal Literaturereview Datacollection Analyzedata Dissertationplanandfirstdraft Seconddraft FinalSubmission Completion(attheendofthegivenmonth) October2009 December2009 March2010 May2010 July2010 December2010 January2010

57

AppendixBProjectProposal
(Astheoriginalprojectproposalwasbroadinscopetheresearchprojectwasnarroweddowntofinding thekeydesignandhumanfactorprinciplesbehindtheextensibilityintheOpenMRSarchitecture.) Introduction OpenMRSisacommunitydevelopedopensourcemedicalrecordsystem.Theprojectisledbythe RegenstriefInstituteandthePartnersinHealthorganizationsandfundedbytheWorldHealth Organization(WHO),theCenterforDiseaseControl(CDC),TheRockefellerFoundation,andthe President'sEmergencyPlanforAIDSRelief(PEPFAR).Thedevelopmentcommunityisscatteredall aroundtheworldledbydevelopersinIndianapolisandBoston. Theprojectusesopensourcetoolsandtechnologies.ItusesJava,Springframework,SpringMVC, Hibernate,MySQL,jQueryandDWRandtoolssuchasEclipse,BIRT,Ant,Subversion,BambooandTrac. TheEclipseenvironmenthasbeenextendedwithOpenMRSspecificpluginstohelptheOpenMRS developersbuildextensionseasily.TheOpenMRSmodulesusevarioustoolssuchasJasperReports, XtreamandintegratewithproductslikePentahosuiteoftoolssuchasKettle.Onenotableexceptionis thattheprojectusesMicrosoftInfopathproprietarysoftwareforformentryfunctions.Ithasbeenused becauseatthetimewhenthesystemwasdevelopedtherewasnoalterativesolutiontosatisfythe requirementswithlesseffortandtime.AnalternativewebbasedHTMLformentrymodulehasbeen developedandisunderactivedevelopmentatthemomentasareplacementforthis. IthasbeendeployedinmanycountriessuchasKenya,Rwanda,Tanzania,SouthAfrica,Lesotho, Zimbabwe,Mozambique,Uganda,PakistanandUSA.Thesystemrunsinregionswithlimitednetwork availabilityandlowresources.Otherthanbeingusedasageneralpatientrecordsysteminhospitals,itis usedintheHIVtreatmentinKenya,Rwanda,Tanzania,multidrugresistanttuberculosisstudiesinPeru aswellasforpaediatricclinicsinIndianaandtuberculosistreatmentclinicsinLosAngeles,USA. Eachofthesedifferentimplementationshasdifferingrequirementsandexpectationsfromthebase system.Itcannotsatisfyalltheserequirementsoutofthebox.Sothedevelopershavedesignedthe systemwithextensibilityinmind.OpenMRSdatamodelisextensibletosupportthesevaried requirements.Implementerscandesignthedatamodeltosuittheirrequirementsandatthesametime makesurethattheinformationthatisstoredcanbetransferablebetweendifferentimplementations. OpenMRSusesmodulestoextendthefunctionalityofthesystemsodeveloperscanwritenew extensionsandplugthemintothecoresystemseamlessly.Themodulescansupportnewadditionsin 58

thepersistencelevelorintheserviceleveloraddormodifythewebbaseduserinterfaceorconnecta differentuserinterfacesystemtothecoresystemaltogether.Forexamplethedevelopercancreate newdatabasetablesorappendexistingcoredatastructuresorintheuserinterfacetheycancreatenew elementsorreplacetheexistinginterfaceelementsdeclarativelyusingextensionpoints. Theresearchquestionofthisprojectistofindouthowthisextensibilityisachievedbyadetailed analysisofthedatastructures,algorithms,thedesignandtheimplementationofthesystem.The objectivesareasfollows. AnalyzetheOpenMRSarchitecturetofindouthowitsupportsextensibility Thetechniquesandpracticesusedintheextensibilityatdifferentlevels,suchasdatamodel, userinterface,serviceorpersistence Studythedatamodelandhowitsupportsextensibilitytosupportdifferentscenariosthrough casestudies Studythemoduleorpluginarchitecturewhichisthemainextensionmechanismforextending thesystemanditsextensionpoints Whatarethelimitationsandshortcomingsinthecurrentarchitectureandhowtheycanbe overcome Howthedesignanddevelopmentiscontrolledtosupportadditionstosupportextensionsand howthecommunityofdevelopersprioritize,decideuponenhancementsandextensions Howthedocumentation,supportandmaintenanceandownershiparehandled Howdoestheprojectsupportbackwardcompatibility,theusabilityrequirementswhile extendingthesystem Investigatehowtheextensionmechanismssupportdifferentlevelsofthesystemsuchas developerleveltasksaswellasimplementeroruserleveltasks

Someoftheobjectivessuchasusabilityandbackwardcompatibilityarenotspecifictoanextensible architecturebuttotheoverallsystem.Buttheyareimportant.Forexamplebecausetheusersofthe systemarebusyhealthworkerswhoarenotexpertsinusingcomputers,themodulearchitectureshould besimplesothattheycaneasilyinstallnewmodulesandconfigurethesystemaseasyaspossible.If installingamodulemeansgoingthroughmanystepsandproceduresthentheextensibilitydoesnot satisfytheusabilityrequirementsofthetargetaudience. WhiledoingthisresearchprojectIwillbeworkingwiththeprojectcommunityandcontributingtothe projectbydevelopingenhancementsandextensions.Thefindingswillbeimportanttotheprospective implementerswhoareassessingwhethertousethesystemandthepresentimplementerswhoare

59

extendingthesystemandanalyzinghowtheinformationshouldberepresentedintheOpenMRSdata model. Theprojectoutcomewillbeusefulforthenewcomersandtheprospectiveimplementersoftheproject tounderstandtheextensiblearchitecturewhichhasbeenbuiltiterativelyovertheyears.While contributingtotheprojectIwillhavetheopportunitytoworkwithanactivedevelopercommunity helpingtobuildasystemthatservesthehealthcarefieldmainlyAIDSvictimsintheAfricanregion.I hopetocontinueworkingfortheprojectbeyondtheresearchprojectduration. LiteratureSurvey Mamlin,etal.,2006describesthebeginningsoftheproject.IndianaUniversitySchoolandMoi UniversitySchoolofMedicinecollaboratedtocreatetheMedicalRecordSystem(MMRS)whichwas developedusingMicrosoftAccessandwhichwasdeployedinKenya.ThesystemwasusedinAMPATH (AcademicModelforthePreventionandTreatmentofHIV/AIDS)project.Thesystemwasnotadequate tosupportmanylocationsandtohandlehundredthousandpatients.Afterevaluatingexistingsolutions theycameupwithAMRS.AMRShasanextensibledatamodel.Insteadofaflattablestructurewhere eachpatientdatapointisrecordedbyacolumn,AMRSmodelusesthestackedmethodorentity attributevalueapproachwhereaflatrowofdataisrepresentedbyastackofrowsforeachpatient.The designgoalsofAMRSwerecollaborationofthecommunitytobuilduponacommoninfrastructure, scalabilitytosupportmanylocationsandhundredthousandpatients,flexibiliitytosupportnotonlyHIV carebutgeneralclinicalscenarios,rapidformdesignfordataentry,clinicallyusefulgatheringofdata, useofstandardsthemedicalfieldsuchasHL7,LOINC,ICD10,SNOMEDandCPT,supporthighquality researchusingthecaptureddata,webbasedwithsupportforintermittentconnectionsindeveloping countriesandlowcostsolutionusingfreeandopensourcetools(Mamlin,etal.,2006).AMRSsystem wasdevelopedusingPython,PloneandMySQL. Wolfe,etal.,2006describeshowtheAMRSteampartneredwiththePartnersinHealthtoform OpenMRSprojectin2004.PartnersinHealthwereinvolvedindevelopingasystemtosupportmulti drugresistanttuberculosisstudiesinPeru.Thegoalofthecollaborationwastocreateanapplication programminginterface(API)encapsulatingthedatamodelandtodevelopawebbasedapplication.The APIisseparatefromthewebintefacesuchthattheAPIcanbeaccessedthoughothermediumssuchas mobileappliances.Thismeansthatthedatagatheringanddisseminationisnotconstrainedintoisolated silos.TheuserinterfacecouldbeWindowsapplications,Javaapplications,webapplications,programs

60

runninginpersonaldigitalassistants,voiceinterfacethroughphoneorscannedpaperformsthrough opticalcharacterrecognitionetc. Fraser,etal.,2005describesthepotentialbenefitsofasuccessfulelectronicmedicalrecordsystem. Thesebenefitsaretheimprovementofthelegibilityofclinicalnotes,decisionsupportfordrugordering, includingallergywarningsanddrugincompatibilities,reminderstoprescribedrugsandadminister vaccines,warningsforabnormallaboratoryresults,supportforprogrammonitoring,includingreporting outcomes,budgetsandsupplies,supportforclinicalresearch,supportformanagementofchronic diseasessuchasdiabetes,hypertensionandheartfailure.Althoughagenericsystemwillnotsupportall thefeaturesoutoftheboxitshouldbeextensiblesothatdeveloperscanextendthesystemtosupport therequirements(Fraser,Biondich,Moodley,Choi,Mamlin,&Szolovits,2005).Thedatamodelplaysa majorpartinextensibility.OpenMRSusesaconceptdictionarywherethedatapointsarefirstdefinedto thesystem.Thepatientdataarecapturedusingthesecodeddata.Usingcodeddatainsteadoffreetext givemoreversatilityanddatasearchandmanipulationabilities.Alsothedatacanbecompared betweentwosystemsaccurately. Theselectedpaperscoverthehistoryoftheproject,howitcameintoexistenceandthetopleveldesign decisions.Throughthisresearchitishopedtoexplainhowthisextensibilityisachievedinthesystemby investigatingadetailedanalysisofthesystem. Thedevelopmentisaniterativeprocess.Itisnotpossibletoforeseeaperfectdesignatthebeginning. ForexampleintheOpenMRSdatamodelatonetimethepatiententityhadatribeattribute.This attributewasrelevantintheinitialdayswhenthesystemwasdeployedintheAfricancountries.But todayitisnotrelevantwhentheprojectisdeployedinotherregions.Sothetribeattributehasbeen movedintoanattributeofthepersonentityinsideamodulesothattheimplementerswhoneedthe tribeattributecaninstallthemoduletohavethatfeaturewhileotherswillnotbeburdenedwiththe redundantelement. Butinthiscasemovingacoreelementintoapluggablemoduleintroducesnewproblemsandnew requirementsintheextensionmechanisms.Sotheextensionmechanismshavetobeappendedto supportthat.Theseimprovementswillimprovetheextensionmechanismsmakingiteasierfornew requirementstobeimplementedinthefuture.Alsoamajorissueinthiscasewasthebackward compatibilitytoidentifyhowtheupgradewillbehave.Thenewtribemoduleshouldupgradeanexisting oldreleaseconvertingolddataintonewformataswellasrunonanewcleanrelease.Theupgrade 61

shouldhappenwiththeminimuminvolvementoftheuser.Iwillinvestigatesuchdetailsinthisresearch project. ResearchMethodology Inthisresearchprojectmainlyethnographicalmethodswillbeappliedtostudyandobservethesystem. Itwillbeaqualitativeresearchwhereresultscannotbemeasuredinexactquantities.Iwillbeworking andcontributingtotheOpenMRSprojectovertheresearchperiodandbeyond.InthiswayIwillbeable tostudyandobservetheOpenMRSdevelopersandcontributorsdistributedaroundtheworld,howthey worktogethertobuildandenhancethesystem.Inthiscontextthecommunicationwilltakeplace throughmailinglists,emails,IRC,instancemessaging,etc.Thisgivesmeanopportunitytojoinanactive communityofopensourcedevelopersandobservethemwhilecontributingtotheopensourceproject. Whilecontributingtothesystemtheextensionmechanismshavetobestudiedandusedtoimplement thefeatures.Thedatamodelhastobeinvestigatedandusedinthedevelopment. Casestudiesonhowotherimplementershaveextendedthecoresystemtosupportdifferentscenarios areusefultounderstandhowextensibilityisachievedinthesystemintherealworld.Casestudieswill revealthestrengthsandtheweaknessesoftheextensiblearchitectureinpractice.Asetofinteresting scenarioswherethecoresystemhasbeenextendedandusedfordifferentpurposeshastobeselected forthecasestudies. Amajorproblemwiththeopensourceprojectsisthelackofqualitydocumentation.Thereisonly rudimentarydocumentationavailableandmostofthetimeitisoutdatedanddifferentfromtheactual implementation.IhopethroughthisresearchIcanmakeacontributioninthedocumentationarea. Theresearchwillalsouseinterviewsandsurveyswiththedevelopers,contributorsandtheusers.The interviewscouldbestructuredoritwillinvolveinformalconversations.Indistributedopensource projectsthemainsourceofcommunicationsisthroughemails,mailinglists,instancemessagingandIRC etc.Interviewswillusuallyinvolvedevelopersandcontributorsrespondingtoquestionsor expressingtheirthoughtsaboutatopicinconversations. Asurveywhichisastructuredlistofquestionspresentedtoasetofpeopleisanotheroptiontogather data.Surveysmaybewrittenororal,facetofaceoroverthephone.Butinthiscaseitwillbemainly throughemailsdistributingthequestionstoatargetedaudiencewhetheritisthedevelopers, contributorsorimplementers.Usingsurveysitispossibletoeasilyandcheaplyextractinformationfrom

62

largenumbersofpeople,butthedataqualityistoldtobelowerthanothermethods.Thereasonisthat peopledonotalwaysanswerquestionsaccuratelyorspendtimeonansweringthem. GatheringandAnalyzingData Thecurrentarchitecturehastobestudiedatahigherlevel.TheOpenMRSdatamodelandthemodule architectureneedtobestudiedandhowitisappliedtosolvedifferentproblems.Thedifferentmodules willbeinvestigatedandwhichextensionmechanismsareusedtobuildthemwillbestudied.Adetailed technicallevelreviewhastobedonetounderstandthedesignandthearchitecturebecausemostopen sourceprojectsdonothavedetaileddocumentationasdevelopersaremoreinterestedindeveloping thesystemthanwritingaboutit.Readingcodeisthemainsourceofknowledge.Thisisagood opportunitytolearnhowsuccessfulprojectshavebuilttheirsystems.Thecoredeveloperswillbe interviewedtoelicitthedesigndecisions. Asetofpracticalscenarioswhereextensionsweredevelopedarestudiedthroughcasestudies, interviewswiththeimplementers.Theinformationgatheredbythecasestudieswillbeveryhelpfulto understandhowtheextensibilityhasbeenusedintherealworldandtounderstandtheirstrengthsand theweaknesses. Experimentscanbeperformedtounderstandtheeffectofstorageconsumption,performancelevel betweentheflatdatamodelandthestackedrowmodel. Thedevelopersandthecontributorswillbeinterviewedtogatherdataabouthowthearchitecturewas designedandwhyitwasdesignedthisway.Dependingontherequirementthemodulecontributorsand implementerscanbesurveyedtogatherdataabouttheissuesandlimitationstheyfacedwhile extendingthesystem.Themajorobstacleswillbetounderstandtheclinicaldatamodelandto understandthecurrentarchitectureandhowitisbeingused.InthiscaseIwillapproachtheprojectasa contributor.Thishastheadvantageoflearninghowapersonwillunderstandthearchitectureanduseit toextendthesystem. Ethics Ethicalconsiderationshavetobeobservedinworkingwiththemedicalrecordsystemwhichstores patientdata.Securitymechanismsaredesignedtoprotecttheconfidentiality,privacyandintegrityof thesystem.FortestinganddemonstrationpurposestheOpenMRSdevelopersuserealpatientdatasets gatheredattheimplementationsitesafterrandomizingandshufflingthepatientidentifiabledata.In

63

thiswaydevelopershaveaccesstosampledatasimilartotherealworldsituationswithoutviolating privacyandconfidentialityofthepatientdatatotestthesystem. Whileinterviewingandifcarryingoutsurveys,theprivacyandconfidentialityofthepeoplehastobe protected.Interviewershouldensurethatintervieweesareadequatelyinformedaboutthenatureof datacollectedwhenseekingconsentforinterviewsandsurveys.Ininterviewstheintervieweeshouldbe informedthepurposeofthedatagatheringandhowthedatawillbeused.Ifthepeoplerequestfor anonymityitshouldbehonored. OutcomesoftheResearch OpenMRSarchitecturewillbeanalyzedfromthetoplevelandthenanalyzedineachlevelinturn.The designdecisionsandtechniquesusedinsupportingextensibilityinOpenMRSwillbepresented.The designandthetechniquesusedtosupportextensibilityatdifferentlevelsinthearchitecture,suchasin thedatamodel,userinterface,servicelevelorpersistencelevelarepresented.Howthedatamodel achievesextensibilitywillbeanalyzed. Howthedevelopershaveusedtheextensiblefeaturesinthearchitecturewillbepresentedthrough casestudiesindifferentscenarioswherethesystemhasbeenextended.Thestrengthsandthe weaknessesofthecurrentarchitecturecanbefoundout. TheOpenMRSmodulearchitecturedesigndecisionsandshortcomings,howdesignanddevelopmentis controlledtosupportadditionstosupportextensions,howthecommunityprioritize,decideupon enhancementsandextensionsandhowthedocumentation,supportandmaintenanceandownership arehandledwillbeanalyzed. Theresearchprojectwillevaluatehowasystemcouldbedevelopedtosupportextensibility. Bibliography Allen,E.(2001).DiagnosingJavaCode:Designingextensibleapplications,Part1.Retrievedfrom developerWorks:http://www.ibm.com/developerworks/java/library/jdiag0925/index.html Annas,G.J.(2003).HIPAARegulationsANewEraofMedicalRecordPrivacy?NewEnglandJournalof Medicine. Anokwa,Y.,Hartung,C.,Brunette,W.,Borriello,G.,&Lerer,A.(2009).OpenSourceDataCollectionin theDevelopingWorld.IEEEComputer. 64

Chang,F.,Dean,J.,Ghemawat,S.,Hsieh,W.C.,Wallach,D.A.,Burrows,M.,etal.(2006).Bigtable:A DistributedStorageSystemforStructuredData.SeventhSymposiumonOperatingSystems DesignandImplementation. Clayberg,E.,&Rubel,D.(2006).Eclipse:BuildingCommercialQualityPlugins.AddisonWesley Professional. EMRExperts.(2010).RetrievedfromEMRExperts:http://www.emrexperts.com/ Fraser,H.S.,Biondich,P.,Moodley,D.,Choi,S.,Mamlin,B.W.,&Szolovits,P.(2005).Implementing electronicmedicalrecordsystemsindevelopingcountries.InformaticsinPrimaryCare. Gamma,E.,Helm,R.,Johnson,R.,&Vlissides,J.(1994).DesignPatterns:ElementsofReusableObject OrientedSoftware.AddisonWesleyProfessional. Gill,J.,&Johnson,P.(2002).ResearchMethodsforManagers.SagePublications. Hannan,T.,Rotich,J.,&Odero,W.(2000).TheMosoriotmedicalrecordsystem:designandinitial implementationofanoutpatientelectronicrecordsysteminruralKenya.InternationalJournal ofMedicalInformatics. Hunt,A.,&Thomas,D.(1999).ThePragmaticProgrammer:FromJourneymantoMaster.Addison WesleyProfessional. Kelly,A.(2002,August).ThePhilosophyofExtensibleSoftware.ACCUOverloadJournal. LiquiBase.(2010).LiquiBaseManual.Retrievedfromhttp://www.liquibase.org/manual/home Liskov,B.(1987).DataAbstractionandHierarchy.ConferenceonObjectOrientedProgrammingSystems LanguagesandApplications. Lober,W.B.,Wagner,S.,&Quiles,C.(2010,January).Developmentandimplementationofaloosely coupled,multisite,networkedandreplicatedelectronicmedicalrecordinHaiti.ACMSIGOPS OperatingSystemsReview. Mamlin,B.W.,Biondich,P.G.,Wolfe,B.A.,Fraser,H.,Jazayeri,D.,Allen,C.,etal.(2006).Cookingupan opensourceEMRfordevelopingcountries:OpenMRSarecipeforsuccessfulcollaboration. AMIAAnnualSymposiumProceedings. 65

Martin,R.C.(1996).TheOpenClosedPrinciple.C++Report. Martin,R.C.(2000).DesignPrinciplesandDesignPatterns.ObjectMentorInc. Martin,R.C.(2002).AgileSoftwareDevelopment,Principles,Patterns,andPractices.PrenticeHall. McIlroy,M.D.,Pinson,E.N.,&Tague,B.A.(1978).UnixTimeSharingSystemForward.TheBellSystem TechnicalJournal. MediNotes.(2010).RetrievedfromMediNotes:http://www.medinotes.com/ Meyer,B.(1988).ObjectOrientedSoftwareConstruction.PrenticeHall. Microsoft.(2010).SigninganAssemblywithaStrongName.Retrievedfrom http://msdn.microsoft.com/enus/library/xc31ft41%28v=vs.71%29.aspx Noll,J.,&Liu,W.M.(2010).Requirementselicitationinopensourcesoftwaredevelopment:acase study.Proceedingsofthe3rdInternationalWorkshoponEmergingTrendsinFree/Libre/Open SourceSoftwareResearchandDevelopment. OpenEMR.(2010).RetrievedfromOpenEMR:http://www.oemr.org/ OpenMRSAccessLoggingModule.(2009).RetrievedfromOpenMRS: http://openmrs.org/wiki/Access_Logging_module OpenMRSBIRTReportModule.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/BIRT_Report_Module_User_Guide OpenMRSConceptCooperative.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/WorkingGroup/OCC OpenMRSConceptProposalModule.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Concept_Proposal_Module OpenMRSDataModel.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/OpenMRS_data_model OpenMRSDocumentation.(2010).RetrievedfromOpenMRS:http://openmrs.org/wiki/Documentation

66

OpenMRSIDGenerationModule.(2008).RetrievedfromOpenMRS: http://openmrs.org/wiki/Idgen_Module OpenMRSImplementations.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Implementations OpenMRSLocalizationTools.(2010).RetrievedfromOpenMRS: http://openmrs.org/wiki/Localization_Tools OpenMRSModuleRepository.(2010).RetrievedfromOpenMRS: https://modules.openmrs.org/modules/ OpenMRSRolebasedHomepageModule.(2008).RetrievedfromOpenMRS: http://openmrs.org/wiki/Role_Based_Homepage_Module OpenMRSSOAPWebServicesModule.(2009).RetrievedfromOpenMRS: http://openmrs.org/wiki/SOAP_Web_Services OpenMRSSourceCode.(2010).RetrievedfromOpenMRS:http://dev.openmrs.org/browser OpenMRSSqldiff.(2008).RetrievedfromOpenMRSSqldiff: http://openmrs.org/wiki/Module_sqldiff_File OpenMRSSyncModule.(2010).RetrievedfromOpenMRS:http://openmrs.org/wiki/Sync_Module OpenMRSTribeModule.(2008).RetrievedfromOpenMRS:http://openmrs.org/wiki/Tribe_Module OWASP.(2010).OWASPTopTenProject.Retrievedfrom http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project PRAXIS.(2010).RetrievedfromPRAXIS:http://www.informed.com/ Ramsdale,C.(2010).LargescaleapplicationdevelopmentandMVP.RetrievedfromGoogleWebToolkit: http://code.google.com/webtoolkit/articles/mvparchitecture.html Rotich,J.,Hannan,T.,&Smith,F.(2003,July).InstallingandImplementingaComputerbasedPatient RecordSysteminSubSaharanAfrica:TheMosoriotMedicalRecordSystem.Journalofthe AmericanMedicalInformaticsAssociation.

67

Rudestam,K.E.,&Newton,R.R.(2001).SurvivingYourDissertation:AComprehensiveGuidetoContent andProcess.SagePublications. Rugaber,S.,Ornburn,S.B.,&LeBlanc,R.J.(1990,January).RecognizingDesignDecisionsinPrograms. IEEESoftware. Stylos,J.,&Myers,B.(2007).MappingtheSpaceofAPIDesignDecisions.SymposiumonVisual LanguagesandHumanCentricComputing.IEEE. Sun.(2010).SigningCodeandGrantingItPermissions.Retrievedfrom http://download.oracle.com/javase/tutorial/security/toolsign/index.html Tavares,A.L.,&Valente,M.T.(2008,September).AgentleintroductiontoOSGi.ACMSIGSOFT SoftwareEngineeringNotes. Trujillo,S.,Azanza,M.,Daz,O.,Capilla,R.,&Sebastian,S.(2007).ExploringExtensibilityofArchitectural Design.WorkshoponSharingandReusingArchitecturalKnowledge.IEEE. VistA.(2010).RetrievedfromVistA:http://vistapedia.net/index.php?title=Main_Page WeberJahnke,J.H.,&Price,M.(2007).EngineeringMedicalInformationSystems:Architecture,Data andUsability&Security.29thInternationalConferenceonSoftwareEngineering,IEEE. White,T.(2009).Hadoop:TheDefinitiveGuide.O'ReillyMedia. Whitson,G.(2009).HealthLevelSeven:TheCornerstoneofMedicalInformatics.JournalofComputing SciencesinColleges. Wilson,G.,&Oram,A.(2007).BeautifulCode.O'ReillyMedia. Wolfe,B.A.,Mamlin,B.W.,Biondich,P.G.,Fraser,H.S.,Jazayeri,D.,Allen,C.,etal.(2006).The OpenMRSsystem:collaboratingtowardanopensourceEMRfordevelopingcountries.AMIA AnnualSymposiumProceedings. Wolfinger,R.(2008).PluginArchitectureandDesignGuidelines.OOPSLA. Yourdon,E.(2006).JustEnoughStructuredAnalysis.

68

Zenger,M.(2004).ProgrammingLanguageAbstractionsforExtensibleSoftwareComponents.Swiss FederalInstituteofTechnology,Lausanne,Switzerland.

69

AppendixCOpenMRSSystemArtifacts
ModuleFolderStructure
build Containstheintermediatebuildfiles dist Containsthefinalrelease lib Dependencyjarfiles libcommon Dependencyjarfilesrequiredonlyatcompiletime metadata config.xml Moduleconfiguration *.hbm.xml CustomHibernatemappings messages_*.properties Internationalizationfiles moduleApplicationContext.xml ModulespecificSpringbeanconfigurationfile liquibase.xml Datamigrationscript src Sourcecode web module JSP,HTMLfiles portlets Customportlets resources Imagefilesetc. tags JSPtags taglibs JSPtaglibfiles src SpringMVCcontrollersandServlets build.xml Thebuildscript

70

SampleModuleConfigurationFile
<?xmlversion="1.0"encoding="UTF8"?> <!DOCTYPEmodulePUBLIC"//OpenMRS//DTDOpenMRSConfig1.2//EN" "http://resources.openmrs.org/doctype/config1.2.dtd"> <moduleconfigVersion="1.2"> <id>example</id> <name>Example</name> <version>0.1</version> <package>org.openmrs.module.@MODULE_ID@</package> <author>JohnDoe</author> <description>ExampleModule.</description> <activator>@MODULE_PACKAGE@.ExampleActivator</activator> <require_version>1.5</require_version> <extension> <point>org.openmrs.admin.list</point> <class>@MODULE_PACKAGE@.extension.html.AdminList</class> </extension> <advice> <point>org.openmrs.api.FormService</point> <class>@MODULE_PACKAGE@.advice.AppendFormAdvisor</class> </advice> <privilege> <name>ViewImages</name> <description>Allowsusertoviewimages</description> </privilege> <globalProperty> <property>@MODULE_ID@.someProperty</property> <defaultValue></defaultValue> <description>Systemwideconfigurationdata.</description> </globalProperty> <!Accessedby/pageContext()/moduleServlet/<moduleId>/<servletname>> <servlet> <servletname>image</servletname> <servletclass>@MODULE_PACKAGE@.web.ImageServlet</servletclass> </servlet> <messages> <lang>en</lang> <file>messages.properties</file> </messages> </module> 71

SampleModuleApplicationContextConfiguration
<?xmlversion="1.0"encoding="UTF8"?> <!DOCTYPEbeansPUBLIC"//SPRING//DTDBEAN//EN""http://www.springframework.org/dtd/spring beans.dtd"> <beans> <beanid="exampleUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <propertyname="mappings"> <props> <propkey="module/example/patient.list">exampleListController</prop> </props> </property> </bean> <beanid="exampleValidator" class="org.openmrs.module.example.web.controller.exampleValidator"/> <beanid="exampleListController" class="@MODULE_PACKAGE@.web.controller.exampleListController"> <propertyname="commandName"><value>exampleList</value></property> <propertyname="formView"><value>/module/@MODULE_ID@/exampleList</value></property> <propertyname="successView"><value>example.list</value></property> </bean> <beanparent="serviceContext"> <propertyname="moduleService"> <list> <value>@MODULE_PACKAGE@.exampleService</value> <beanclass="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"> <propertyname="transactionManager"><refbean="transactionManager"/></property> <propertyname="target"> <beanclass="@MODULE_PACKAGE@.impl.exampleServiceImpl"> <propertyname="exampleDAO"> <beanclass="@MODULE_PACKAGE@.db.hibernate.HibernateexampleDAO"> <propertyname="sessionFactory"><refbean="sessionFactory"/></property> </bean> </property> </bean> </property> </bean> </list> </property> </bean> </beans>

72

AppendixDSampleQuestionnaire
(Questionsweredescriptiveandopenended.Allquestionsrelatedtoasinglepointweregrouped together.Otherwisethewriterhastoreferencepointsbetweeneachother.Theintentionofthe questionnairewastoextractpointersforfurtherinvestigationthroughinterviewsandanalysisofthe systemandthearchitecture.) 1. WhatisyourroleinOpenMRSfromthefollowing(Selectoneormore)? Coredeveloper Moduledeveloper Implementer User Other(Specify) 2. HowlonghaveyoubeeninvolvedwithOpenMRS? 3. FromyouexperiencecouldyoulistfeaturesfoundintheOpenMRSarchitecturethatinyour viewfacilitatesorhelpswhenextendingtheOpenMRStohandlenewuserrequirements? 73

4. Couldyoulistthelimitationsyouhavefacedwhendevelopingyourextensions,howdidyou overcomethemandifnothowdoyouproposetoovercomethem?

74

AppendixEInterviewSchedule
1. WhatisyourroleinOpenMRS? a. HowdoyouinvolveinOpenMRSfromthefollowing? i. Coredeveloper ii. Moduledeveloper iii. Implementer iv. User b. Howlonghaveyoubeeninvolvedin? 2. WereyouinvolvedintheinitialstagesoftheOpenMRSdesign? a. IfsohowdidyoumakeOpenMRSextensiblesothatitisflexibleenoughtohandle differentscenariosandusages? b. CanyouthinkofanykeydesigndecisionsthatweremadeduringOpenMRSdesignand developmentrelatedtoextensibility? c. Werethereanyprominentissuesfacedbythedesigners? 3. WhendevelopingtheOpenMRSarchitecture,thedatamodel,pluginarchitecturewhatspecific designdecisionswereconsideredtomakeitextensible? a. Whatdesignideaswerethealternatives? b. Whyweretheychosenassuch? c. Whatdesignideaswerediscarded? 4. CouldyoulisttheextensibilityfeaturesprovidedbyOpenMRS?(E.g.Keyvaluedatamodel) a. Whatarethemostimportantextensibilityfeaturesfromtheonesyouhavelisted? 5. Couldyoulistthelimitationsyouhavefacedwhendevelopingyourextensions a. Howdidyouovercomethem? b. Ifyoucouldnotovercomethem,howdoyouproposetoovercomethem?

75

AppendixFQuestionnaireandInterviewResults
ThefollowingisacompilationofthefeaturesthatimprovetheextensibilityintheOpenMRS architecturesummarizedfromthequestionnaireresponsesindescendingorderonresponsefrequency. ThesepointsarefurtherexplainedinthechapterDesignPrinciplesAnalysiswhenexplainingthedesign principlesusingthesedataincontext.Parenthesescontainbriefexplanationsorcommentswhen necessary. 1. Aspectorientedprogramming Hookableservicecall.ConsumercanhookmoreAPIcalltothebaseAPIcreatingaside effectofanevent.Example:generateapatientreportwhenanewencounterforapatientis entered 2. Keyvaluepairmodelusedintheconceptdictionary,encountersandobservations Conceptdictionarydefinestheconceptmetadata 3. Conceptscanhavemultiplenames/synonyms 4. Modulesystem 5. Personattributetype 6. Multiplepatientidentifiertypes 7. UsingInfoPathfordatacollection 8. Extensiblewebinterface ExtensionpointsallowyoutoextendtheUIlayerofOpenMRS 9. UseofHL7 UsingHL7queueforenteringpatientdata 10. User,roleandprivilegesarchitecture 11. Patientdashboardextensions,gutterextensions(Thesearewebinterfaceextensionpoints.) 12. Creatingnewdatabasetablesandhibernateservices 13. CreatingnewinterfaceswhilestillaccessingthedesigntemplatesofOpenMRS

76

14. OpenMRSisbuiltforanyfrontendpresentationlayer.TheAPIisnotawareofthecurrentweb layerandsotheAPIcanbeusedinmultipledifferentenvironments. Thefollowingisasummaryoftheweaknessesfoundintheexistingarchitectureaccordingtothe questionnairesandtheinterviews.TheselimitationsarepointedoutintheOpenMRSLimitationssection aswellaswhendescribingthefeaturesincontextinthechapterFurtherAnalysisofDesignPrinciples. 1. Weaknessofobservationsstackedmodeliswhenperformingresearchandreporting,for exampleonceyouhave70millionobservations,itwillneedafastercomputerorneedtoextract dataoutintoaflatonequestionpercolumnviewwithadatatransformationtool. 2. NotbeingabletoholdhierarchicalmedicalvocabulariesorontologieslikeSNOMEDwithinthe conceptdictionary 3. Beingabletobuildoffthemodulesofotherpeople,andbeingabletomergethem(insteadof havingyourcopyandtheircopy,beabletointegratethemsomehow,withoutmakingittoo specifictoyourimplementationofOpenMRS,orallowforplacesinmodulestohookintothe othermodules.)Thatismoduleintercommunication. 4. Downsideofmodulesisthatthecoredeveloperscannotdowidesweepingrewritesbecauseit willbreakallthemodulesoutthere.Thatisbackwardcompatibility.

77