collaborative health platform - colleaga · part of the system. this logical architecture is...

CollaborativeHealthPlatform

DesignSpecification&AnalysisReport

Version:1.2

OriginalPublicationDate:12/2/2011Thisrevision’spublicationdate:4/30/2013CurrentRevision#:7

CollaborativeHealthPlatformSpecification 2

TableofContents

TableofContents.........................................................................................................................................2

DocumentInformation.................................................................................................................................3

OriginalAuthors.......................................................................................................................................3

VersionHistory.........................................................................................................................................3

RelatedDocuments..................................................................................................................................3

ExecutiveSummary......................................................................................................................................4

Definitions................................................................................................................................................4

Purpose....................................................................................................................................................5

Scope........................................................................................................................................................5

Methodology............................................................................................................................................5

SoftwarePackagesReviewed...................................................................................................................6

StandardsReviewed.................................................................................................................................7

DesignOverview...........................................................................................................................................8

SystemSummary......................................................................................................................................8

Identifiers.................................................................................................................................................8

Constraints...............................................................................................................................................9

BusinessRequirements............................................................................................................................9

SystemArchitecture...................................................................................................................................10

SystemOverview....................................................................................................................................10

SoftwareArchitecture............................................................................................................................12

DataArchitecture...................................................................................................................................72

CommunicationsArchitecture...............................................................................................................73

Network/PhysicalArchitecture............................................................................................................95

TechnicalScenarios................................................................................................................................98

Role&OperationReference....................................................................................................................109

TableofFigures........................................................................................................................................111


DocumentInformation

OriginalAuthors• JustinFyfe,ResearchProjectManager(Software),MohawkCollege

VersionHistoryVersion Author Date Changes

1.0 JustinFyfe(MohawkCollege) 12/02/2011 InitialVersion1.01 DerekRitz(ecGroupInc) 01/03/2012 1.1 JustinFyfe(MohawkCollege) 12/12/2012 UpdatedtoincludeFRED1.0specification

inanalysisandexamples.1.2 JustinFyfe(MohawkCollege) 03/20/2013 UpdatedtoincludeFRED1.0specification

examples.

RelatedDocumentsDocumentLink RelevanceNetHopePEPFARmHealthInteroperabilityProjectIntroduction

UseCaseSummarization&HighLevelSequenceDiagrams

11-10-12UseCaseStories(draft0.3) UseCaseStories&DataRequirements11-08-09Cartoon-ishstoryboardforCHPproject

Zambia&RwandaProjectSummarization

20-03-13FREDAPI.xps FREDAPISpecificationDocument

COPYRIGHT STATUS: This work, authored by Mohawk College of Applied Arts and Technology, subcontractor/employee of NetHope, was funded in whole or in part by the United States Agency for International Development (USAID) under U.S. Government contract #AID-CIO-A-10-00001, and is, therefore, subject to the following license: The Government is granted for itself and others acting on its behalf a paid-up, nonexclusive, irrevocable worldwide license in this work to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government. All other rights are reserved by the copyright owner.Theauthor’sviewsexpressedinthispublicationdonotnecessarilyreflecttheviewsoftheUnitedStatesAgencyforInternationalDevelopmentortheUnitedStatesGovernment.

ExecutiveSummaryTheCollaborativeHealthPlatform(CHP)ispartnerdriveninitiativetodevelopacohesivem&eHealthecosystemthatfacilitatesthedeliveryofhealthcareinresourceconstrainedenvironments.Theavailabilityofmobilehandsetsindevelopingcountriesbundledwiththequicklymaturingnetworkcapabilitieshasgivenrisetoanumberofmobilehealthcaresolutionsthattargetdevelopmentobjectives.

Theriseofmobilehealthsolutionsinresourceconstrainedjurisdictionshasgivenneedforinteroperability(fordonorsandimplementers)throughastandardsbasedapproach.

Definitions1. “Client”isusedinthisdocumenttodescribeaconsumerofhealthcareservices,andismost10

ofteninterchangeablewiththeterm“patient”2. “Provider”isusedinthisdocumenttodescribeapersonwhoisprovidinghealthservicestoa

“client”.Theterm“providers”isusedwhendiscussingaCommunityHealthWorker(CHW),Physician,Nurse,orotherhealthcareworkerwhenaccessingthesystem.

3. “User”isusedtodescribeaperson(clientorprovider)whowillusethesystem.Auserhascredentialswhichareusedtoaccessthesystem.Inobjectorientedterms,aclientISAuserandaproviderISAuser.

4. “System”describestheoverallhealtharchitectureandallofitscomponentsandinteractions.ThistermisoftenusedwhendescribingtheentiredeliverableoftheCHP.

5. “HealthInformationExchange”(HIX)describestheintegrationofclinicaldatasourcesforthe20purposeofconsistentaudit,reporting,messaginganddataaggregation.

6. “ConsumerApplications”describessystemsthatwillcommunicatewiththeHIXinaprimarilyconsumerbasedrole.ExamplesofaconsumerapplicationareOpenMRS,CommCare,andChildCount+.

7. “EdgeDevice”or“PointofService”(POS)aretermsusedtodescribethephysicaldevicethatauserwilloperateinordertocontroltheconsumerapplication.Examplesofanedgedeviceincludeacellularphone,anetbookcomputer,orworkstation.Althoughanedgedevicemayexecuteandruntheconsumerapplication(forexample,onasmartphone,orlaptop)therearescenarioswheretheedgedeviceismerelyadataentryfeedtoamorecentralizedconsumerapplication(suchasa“dumb”phoneaccessingRapidSMS).Forthisreasonthetwoare30consideredlogicallyseparateforthepurposeofthisdocument.

8. “Role”–Aroleissimilartoaroleinatheatreplay,ormovie.Itisatypeofcharacterthatparticipatesintheconveyingofaclinicalact.Forexample,theroleofclientregistrymaybeplayedinonejurisdictionbyOpenEMPIandplayedinanotherbyMirthConnect.Althoughdifferentactorsareplayingtheroleofclientregistrytheybehaveinthesameway.

9. “ServiceProvider”-Thetermserviceproviderisusedtodescriberolesthatprovideinterfacesforinvokingoperationsthatresultindatabeingstored,retrieved,orupdated.Forexample,aninstanceofOpenMRSthatisactingasaclientregistryserviceproviderparticipatesinscenariosby“providing”clientdemographicinformation.


10. “ServiceConsumer”–Thetermserviceconsumerisusedtodescriberolesthatconsumethe40servicesofferedbyaserviceprovider.Forexample,aninstanceofOpenMRSthatisfetchingclientdemographicinformationisaclientregistryserviceconsumerasitisperformingtheactionofsolicitingdatafromtheclientregistryprovider.

PurposeThisdocumentprovidesaseriesofguidelines,analysisandspecificationsoutlininghowintegratingopensourcesolutionscurrentlydeployedintheseenvironmentscanbeachieved.Specificallythisspecificationprovides:

1. Anidentificationof“roles”thatarerequiredtoexistwithinaninteroperablesystem2. Ananalysisofseveralstandardsbasedinterfacesthatwereidentifiedforcommunicationwith

theintegratedhealthplatform503. Ananalysisofthecapabilitiesofdeployedsystemswithalistintegrationissuesandgapsthat

needtobeaddressed4. Alistofalternateopensourcetechnologiesthatalsoimplementeachservicerole5. Samplemessagesforeachofthestandardsbasedinterfacesidentified6. Sequencediagramsofhowmessagesandoperationscan“flow”betweensystemsandservice

roleswithinthesystem

ScopeThescopeofthedesignsandanalysisinthisdocumentarelimitedtotheusecasesoutlinedinthe“BusinessRequirements”onpage9.Forthepurposeofthisdocument,thefollowingitemsareconsideredin/outofscope:60

InScopeDesignConsiderationsSystemArchitectureLogicalDataDesignServiceRoleIdentification&BehaviorStandardsIdentification&SamplesApplicableOpenSourceSoftwareimplementationsOutofScopeSoftwareDetailedDesignDataDetailedDesignUserInterfaceDesignExecutableSoftware

MethodologyTheteamcollectedcommonusecasesfromthreeprojectscurrentlyunderwayinthefieldincluding:

• HI-PPPfundedprojectinRwandabeingimplementedbyJembi,• HI-PPPfundedprojectinCambodiabeingimplementedbyInSTEDD


• USAIDfundedWVIprojectinZambia

Theusecasesanduserstoriesfromtheseprojectswerecollectedandaggregatedintoaseriesofcommonusecasesreflectedinthe“BusinessRequirements”sectiononpage9.

Fromtheseusecases,aseriesofsequencediagramsdescribingtheuser-userinteractionsweredeveloped.Theseinteractionsdescribethelogicalflowofdatabetweenusersanddescribedtheclinical70scenarioandhowthesystemparticipatesintheseclinicalscenarios.

Basedontheusecasesandsequencediagrams,alogicalarchitecturewasderivedthatdescribedthemajorcomponentsofthesystemandthecommunicationschannelsthatoccurbetweeneachlogicalpartofthesystem.Thislogicalarchitectureisillustratedin“SystemArchitecture”onpage10.Outofthislogicalarchitectureaseriesof“serviceroles”wereidentified,andtechnicalsequencediagramswerecreatedthatidentifiedtheinteractionsthatneededtooccurbetweentheHIXandpointofserviceapplications.

Basedontheserviceroles,aseriesofdatarequirementswereidentified.Usingtheserequirementsaseriesofcandidatestandardsandmessageformatswhereselectedandanalyzedforappropriatenessand“distancetothegoal”.80

Basedontheresultsofthisanalysisaseriesof“recommended”standardsandpatternswhereselected,andanalysisbeganonmappingcurrentlyavailablesoftwareinterfacestothesepreferredstandards.

Technicalartifactsfortheprojectareincludedinthisdocumentinanabridgedform.Fullexamplesandtechnicalartifactsareavailableasasupportfile.

SoftwarePackagesReviewedDuringthedevelopmentofthesespecificationsandguidelines,theCHPteamreviewedtechnicaldocumentationandsampledeploymentsofthefollowingsoftwarepackages:

• RapidSMS/ChildCount+• CommCare(andCommCareHQ)• OpenMRS90• Mirth(MirthConnectandMirthMatch)• ApelonDTS• OpenEMPI• OpenDM-MI• NexJAIP(ProviderRegistry)• InSTEDDTechnologies(Nuntium,Remindem,etc…)• MuleESB• OpenESB• MARC-HIReferenceImplementations(SHR,CRandSDLR)• OpenXDS100• MicrosoftXDS.bDocumentRegistryandRepositorySolutionAccelerator


• FREDAPI1.0

Thefollowingsoftwarepackageswereidentifiedbuthavenotundergonesufficientanalysistobeincludedinthisdocument:

• ez-HIS• Veegilo• MoTECHSuite

Thefollowingsoftwarepackagesarementionedinthisdocumentbutarenotincludedinrecommendationsbecausetheyarenotdistributedunderanopensourcelicense:

• OceanInformaticsOTS110• 3MHealthDataDictionary• HIPAATUniversalAuditRepository• MicrosoftBizTalkServer• IBMWebSphere• OracleWebLogic• DellBoomi• IntelSOAExpressway

StandardsReviewedDuringthedevelopmentofthesespecificationsandguidelines,theCHPteamreviewedthefollowingmessagingstandardsindepth:120

• HL7v22.5• HL7v3• IHEPIX/PDQv2&v3• OMGIXS1.0.1• IHEXDS.b• HL7CDA• IETFRFC-3881&IHEATNA• HL7CTS1.2&2.0

ThefollowingstandardswereidentifiedbuthavenotundergonesufficientanalysisbytheCHPteam:

• OpenEHR130• ISO-13606• IHEProviderRegistryStandard

Thekeytointeroperabilitywithinasystemisconsistentterminologywithindatastructures.ThefollowingstandardizedterminologieswerereviewedbytheCHPteam:

• ICD-10,ICD-10-CM


• LOINC• SNOMED-CT

DesignOverview

SystemSummaryThesystemhasbeenarchitectedinsuchawaythatcurrentimplementationsofopensourcesoftware140canbeintegrated.AllinteractionsbetweentheHealthInformationExchange(HIX)andclinicalservicesareassociatedwithoneormorestandardsbasedinterfaces.

Becausemanysoftwareprojectsinresourceconstrainedenvironmentshavelittleornosupportforstandardsbasedinterfaces,thisdocumentprovidesalternativeinterfacesthatcanbeusedtoperformthesamefunction.Thealternativeinterfacesarecommunicationsinterfacesthat,whilenotstandardsbased,arealreadyprovidedbythesesoftwarepackages(forexample,theRESTAPIforOpenMRS).

Additionally,thesystemandinterfacespecifications/guidanceinthisdocumentdoesnotassumeoneparticulartypeofarchitecture.SequencediagramsinthisdocumentarerepresentedasusinganEnterpriseApplicationIntegration(EAI)patternhowevertheinterfaces,rolesandstandardsidentifiedinthisdocumentcanbeusedwithalternatepatterns.150

ItispossibletoimplementtheHIXdescribedinthisdocumentusingpoint-to-point,monolithicorserviceorienteddesignpatterns.Forexample,amonolithicapplicationmayimplementallrolesidentifiedlocallywithinonesoftwarepackage.However,suchasystemshouldhavethecapabilitytoexposefunctionsinamannerwhichmapslogicallytotheservicerolesidentifiedhere.Ifsuchanapplicationexposesa“ClientRegistry”and“ProviderRegistry”interfacetoexternalsystems,thentheapplicationcanparticipateinotherHIXsasaCRand/orPR.

ItisimportanttonotethatsystemsparticipatingintheHIXshouldhaveknowledgeofotherservicesavailable(howevermaychoosenottousethem).Forexample,asystemactingasasharedhealthrecordrepositoryshouldhavetheabilitytolookupclientdatafromafederatedpatientindex.

Identifiers160Everyroleandoperationdescribedinthisdocumentisgivenauniqueidentifier.Thisuniqueidentifierisameaninglessbutuniqueidentifierandservestounambiguouslyreferencetheconcept.Theseidentifiersareintendedtoassistreaderswhenambiguousnamesareusedforthesameoperation/role.

Forexample,PatientDemographicQuery(PDQ),findcandidates,andgetpatientalldescribethesameoperationindifferentsoftwarepackagesandstandards(IHEPIX/PDQ,HL7v3,andOpenMRSrespectively).Inthisdocument,thepatternoflookingforapatientdemographicisknownas[CR01].

AcompletelistofroleandoperationscanbefoundintheRole&OperationReferencesectiononpage109.


ConstraintsThisprojectwasexecutedwiththefollowingconstraints:170

• Allrecommendationsmustkeepinmindtheusecasesandtechnicallimitationsfoundwithinaconstrainedresourceenvironment,

• Whereverpossible,softwarepackagesalreadydeployedaspartofthethreeidentifiedprojectswereusedasthebasisfortechnicalguidance,

• Internationallyballotedstandardsweregivenpreferenceoverproprietaryinterfacestosoftware,• Onlyopensourcesoftware,orstandardswithopensourceimplementationsareproposed,• Duetothelargeamountofdocumentationsurroundinginternationalstandardsandsoftware

projectsandthetimeconstraintsontheproject,notallstandardsandsoftwarecouldbegivenequalconsideration.Suchcircumstancesareclearlyidentified.

BusinessRequirements180Aseriesofusecaseswereidentifiedaspartofthisprojectwhichservedasthebusinessrequirementsforthisspecification.Pleaserefertotheusecasedocuments(identifiedintherelateddocumentssection)forcompleteusecasestories.

Theserequirementshavebeenparaphrasedforconvenience:

1. Thesystemmustnotassumeedgedevicesusedbyproviderswillhaveprocessing,integrationanddatavalidationfunctionality,

2. Thesystemmustallowausertobereliablyidentifiedusingavarietyofidentificationmechanisms(example:Phone#,PIN,NID,etc…),

3. Thesystemmustallowuserstoauthenticatethemselvesusingamechanismmostappropriatefortheedgedevicetheyareusing(example:Phone#&PIN,Card&Pin,Card&Picture,etc…),190

4. ThesystemmustallowuserstoauthenticateusingthesamePIN/Card/Voice/etc...regardlessofedgedevicethattheyareusing(i.e.:federatedauthentication),

5. Thesystemmustprovideamechanismforupdateuserauthenticationinformation(PIN),6. Thesystemmustallowfornewproviderstobeaddedtothesystembylocalauthorities(CHW

managers,etc…),7. Thesystemmustallowforexistingproviderrecordstobeupdatedafterregistration,8. Thesystemmustallowforthefetchingofproviderinformationandroles,9. Thesystemmustallowfortheonboardingofpatients“in-the-field”,andmustpermitthe“hold”

ofapatientidentifier(i.e.:supportpartialdemographicrecords),10. Thesystemmustallowfortheupdatingofexistingclientdemographicinformation,20011. Thesystemmustallowproviderstoretrievepatientdemographicinformationfromthesystem,12. ThesystemmustallowfortheretrievalofasummaryofpatientPHIbyaprovider.Apatient

summaryisanaggregationofallPHIinallavailableclinicalregistries,13. Thesystemmuststoredemographicinformationseparatelyfromclientinformation,14. Thesystemmustprovideamechanismforrecordingclinicalobservationsaboutaclient,15. Thesystemmustprovideamechanismforrecordingclinicaldiagnosesaboutaclient,


16. Thesystemmustprovideamechanismforreferringclientstospecializedcarecentres,17. ThesystemmustauditalldisclosureandupdateofProtectedHealthInformation(PHI),Patient

DemographicInformation(PDI)andproviderinformation

SystemArchitecture210Thisspecificationisanoverviewoftheroles,functions,dataandcommunicationsinterfacesforaninteroperablehealthsystem.Keytothesuccessofanyinteroperabilityprojectisasetconsistentinteroperabilitytraitsthatsoftwareparticipatinginthesystemshouldexhibit,theseare:

1. BehavioralInteroperability–Servicesandsoftwareparticipatinginaninteroperablesystemshouldexhibitthesamebehaviorswheninvokedbyexternalentities.Thisiskeyifdrop-incompatibilityistobeattained.Thisspecificationoutlinesbehaviorbasedinteroperabilityas“softwarearchitecture”andspecifiescommonpatternsofbehaviorthatareexpectedofeachparticipantwithintheinteroperablesystem.

2. SyntacticalInteroperability–Servicesparticipatinginaninteroperablesystemshouldcommunicatewithacommonstructureandsyntax.Thismeansthatcommondataelements220shouldbepresentandinterpretableinanysystemcommunicatingorreceivingcommunicationswithintheinteroperablesystem.Inthisspecification,syntacticalinteroperabilityisdefinedinthe“dataarchitecture”and“communicationsarchitecture”sectionsandisconstrainedtocommonelementsthatshouldappearineachoftheserviceroles.

3. SemanticInteroperability–Isdescribedastheinteroperabilityofmeaningorlanguagewithinasystem.Thisdiffersfromstructuralinteroperabilityinthatthestructureofadataelementmaybeinteroperable(example:Gender=)butthevaluesmaynotbe(example:Gender=M|FforMale|Femalevs.Gender=F|NforFérfi|Nő).Thisisoftenthemostdifficultinteroperabilitytoachieveasclearcodificationrulesandmappingsneedtobepresent.Manystandardsorganizations(HL7,ISO,ANSI,IETF,OMG,etc…)specifythesemanticmeaningofdataelements230withintheirspecifications.Inthisspecificationsemanticinteroperabilityisidentifiedinthe“communicationsarchitecture”section.

SystemOverviewForthepurposeofdescribingthecomponentsofthesystem,aserviceorientedarchitecture(SOA)nomenclaturewillbeused.SOAmethodologyhasbeenchosenasthepreferredmethodofintegratinganddesigningtheinteroperablesystemforseveralreasons:

1. Theconceptofaservicerole(orapplicationrole)allowsthesystemtobedescribedintermsoffunctionalitythatisprovidedbyoneormorephysicalsystems.Forexample,aninstanceofOpenMRShassufficientfunctionalitytoactasanObservationRepository,andEncounterRepositoryserviceprovider.240

2. UsingaSOAmethodology,thespecificationisnotprescriptiveofphysicaldeployment.Thismeansthathub-and-spoke,servicebus(ESB),orpoint-to-pointinterfacescanbedeployed(althoughtheformertwooptionsarerecommended)andstillusethesameservices.


3. Thesystemisextensiblebyvirtuethatintegrationsbetweentheserviceroleswithinthesystemoccurviamessagingratherthanmonolithicintegration.Thisalsopermitsblack-boximplementationswherefunctionalityofserviceswithintheHIXareusedwithlittleornounderstandingofthemechanicsofeachimplementation.

4. UsingaSOAmethodologypermitseasierscale-upandscale-outpotential.Physicalsystemsimplementingmultipleservicerolescanberedeployedasmanyphysicalsystemsimplementingoneservicerole.Itisalsopossibletoselectivelyscaleupimplementationsofservicerolesthat250requireitwhileleavingotherserviceroles.

Figure1illustratestheservicerolesthathavebeenidentifiedforusewithinthesystem.Eachservicehasbeencategorizedbasedonthegeneralfunctionalityitprovides(categorizationisoutlinedinTable1).LogicalcommunicationsbetweensystemsthatimplementeachoftheservicesisperformedviatheHIXandisillustratedwitharrows.

Figure1-Servicerolesidentifiedforaninteroperablehealthsystem

Clinical Repositories

HIX

Security / AuditServices

Consumer Applications

SMS Gateway IVR Gateway CDA API HL7v3 API

Edge Devices

“Dumb” Phone Smartphone Netbook PC

Orchestration[ROL27]

FederatedSecurity[ROL17]

CertificateServices

AuditRepository[ROL15]

Demographic Registries

Client Registry[ROL01]

Provider Registry[ROL03]

Facilities Registry[ROL05]

Obs Repository[ROL23]

Doc. Repository[ROL11]

Cond. Repository[ROL19]

CHW Clinicians Physicians Healthcare Workers

Terminology Services[ROL07]

Referral Repository[ROL21]

Enc. Repository[ROL25]

SHR[ROL09]

Messaging[ROL13]

Table1–Servicerolegroups


ComponentGroup ContainedServices DescriptionDemographicRegistries ClientRegistry

ProviderRegistryFacilities/LocationRegistry

Theprimaryroleofademographicregistryisthestorageandmatchingofdemographicinformationrelatedtovariousentitiesthatparticipateinhealthcareevents.

ClinicalRepositories DocumentRepositorySharedHealthRecordLabRepositories

ImagingRepositories

Clinicalrepositoriesareresponsibleforthestorageofdatarelatedtohealthcareevents.Theserepositoriescanbegeneralpurpose(suchasadocumentrepository)ortargetedrepositoriesforaspecificpurpose(HIVorTBprogrammerepositories)

HIX Orchestration TheHIXisresponsiblefortheorchestratingandofintegratingthejurisdictionalregistriesandclinicalrepositories.ItisrecommendedthatallHIXfunctionsbewrittenagainstacanonicalform.

Security/AuditServices AuditRepositoryFederatedSecuritySystemCertificateServices

ThesecurityandauditservicesareasetoffederatedservicesthatareusedbytheHIX,RepositoriesandRegistries,andClientstofacilitateenterpriseauthentication,andauditing.

ConsumerApplications SMSGatewaysIVRGatewaysIntegrationAPIs/Toolkits

Thetermconsumerapplicationisusedtorefertogateways,frameworksandAPIsthatwillbeusedtointegrateedgedevicesintothesystem.

EdgeDevices Edgedevicesarethephysicalhardwaredevicesthatwillbeusedbyuserstoaccessconsumerapplications.

260

Eachoftheserviceswithinthesystemexposestheirfunctionalitythroughamessagingparadigm.Forexample;whenasystemthatimplementstheSharedHealthRecordneedstovalidatepatientdemographicinformation,itconsumestheClientRegistryservice(asaClientRegistryServiceConsumer)aspartofitsdatavalidationprocess.

Byfollowingthisparadigm,itispossibletofederatefunctionalityacrosstheheathenterprisewhichallowsforapatientcentricviewofahealthprofile.

SoftwareArchitectureThesoftwarearchitectureforthesystemdescribesthehighlevelcomponentsthatmakeuptheentiresystemasawhole,aswellastheserviceroleswithineachofthelogicalsystems.Thissectionseekstodescribeeachcomponentintermsofthefunctions(operations)theyperformwithinthecontextofan270interoperablesystem.


Thediagramsfoundinthissectionareintendedtoconveytheinvocationpatternofeachroleandoperationratherthanthephysicalmessagingofthesystem.Differentstandardsandsoftwarepackagesusedifferentnamesforthesamepattern,andthesediagramsseektoassistthereaderinunderstandingthepatternofeachoperationatamacrolevel.

ClientRegistryFromasoftwarearchitecturepointofview,theclientregistryisdefinedasaservicethatmaintainsdemographicinformationrelatedtoanyoftheclients(patients)withinthesystem.

Atminimum,theclientregistryshouldbecapableofperformingsearchesbasedondemographicinformation(searchbyname,age,gender,etc…),registrationofpatientdemographicinformation280(add/updatepatientdemographicdata,etc…).Sinceaclientregistryservicewouldbeafederatedidentitymanagementsystem,itmustalsobecapableofresolvingidentifiersacrossmanydifferentsoftwaresystems(i.e.:onepatientwillhavemultipleidentifiers).

RolesTherearethreerolesidentifiedfortheclientregistryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.

• ClientRegistryServiceProvider[ROL01]–Asystemimplementingaclientregistryserviceproviderisresponsibleforthemaintainingthedemographicandidentifierinformationrelatedtoaclient.290

• ClientRegistryServiceConsumer[ROL02]–Asystemimplementingaclientregistryserviceconsumeriscapableofinvokingoperationsonafederatedclientregistryservice.

• ClientRegistryServiceNotificationConsumer[ROL28]–Asystemimplementingtheclientregistryservicenotificationtargetroleiscapableofprocessingclientregistrynotifications.

IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheClientRegistry.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithCRwhichisusedtounambiguouslyidentifytheoperation.


ResolveIdentifier[CR01]

Client Registry Service Provider

[ROL01]

Client Registry Service Consumer

[ROL02]

Resolve Identifier [CR01]

Resolution Resp. [CR02]

Audit Repository[ROL15]

Audit Disclosure [AR01]

Figure2-Resolveclientidentifier[CR01]invocationpattern300

Theresolveidentifier[CR01]operationmustbecapableofacceptingoneormoreidentifiersinoneormoredomainsandmustbecapableofidentifyingthepatientwhoseidentifierswerepassed.Forexample,MosaMuntabemaybepatient123inaTBregistry,butwillbeassigned435intheSHR.ItistheroleoftheClientRegistrytoresolveeitheridentifiertoMosa.

Theresultofthisoperation[CR02]isaclientdemographicrecordthatcontainsalistofalloftherelatedclientidentifiersforthespecifiedclient.

Aswithalldisclosureevents,aclientregistryshouldsupporttheabilitytoauditdisclosure[AR01]toanauditrepository.

PatientDemographicQuery[CR03]


[ROL01]


[ROL02]

Demographic Query[CR03]

Demographic Resp. [CR04]



310

Figure3-Patientdemographicquery[CR03]invocationpattern

Thedemographicquery[CR03]operationmustbecapableofsearchingthelistofpatientsavailablebasedonthename,genderandageoftheclient(atminimum).Theresultofthissearch[CR04]willbealistofpatientdemographicrecordsofthosepatientsthatmatchthesuppliedparameters.


RegisterClient[CR05]


[ROL01]


[ROL02]

Register Client [CR05]

Acknowledgement [CR06]

Client Registry Notification Consumer[ROL28]

Submit Notification [HIX01]


Audit Record [AR02]

HIX[ROL13] New Client Notification [CR07]

Figure4-Registerclient[CR05]invocationpattern

Addregisteroperation[CR05]mustprovidethecapabilitytoregisteraclientwithintheclientregistry.Itispossiblethatthe“new”clientismerelyanewpointeraclientthatalreadyexistswithinanotherregistryorsystem,inwhichcasetheentireavailabledemographicinformationshouldbesuppliedtothe320clientregistry(thereisnoassumptionthattheCRwillin-turn,fetchdemographicinformationfromtheregisteringsystem).Theoperationofaddinganewclientwillresultinanewlocalidentifier(localtotheclientregistry)beinggenerated.Thecreationoftheclientshouldbeacknowledged[CR06]aseitherbeingsuccessful,orfailed.

Sincetheclientregistryparticipatesinasystem(ratherthanstandalone),itmustprovideanotification[CR07]totheHIX[ROL13]thatanewpatienthasbeenadded,theHIXwillin-turnnotifyanynotificationtargets[ROL28]ofthechange.Thisnotificationmustincludedemographicthatwassuccessfullyregisteredwithintheclientregistryservicerole.

ThesequencefortheseoperationsisoutlinedinFigure5.NotethatthissequencediagramdoesnottakeintoaccountthecommunicationsstandardsbetweentheCR[ROL01]andHIX[ROL13],thoseare330identifiedintheCommunicationsArchitecturesectiononpage73.


Client Registry : ROL01Client Reg. Consumer : ROL02 Audit Repository : ROL15

Register Client: CR08()

Audit Record: AR02()

Notification Consumers : ROL28

Notify using CR07: HIX01(){Create Successful}

Acknowledgement : CR09

HIX

Notification: CR07()

Figure5-Registerclient[CR05]sequence

UpdateClient[CR08]


[ROL01]


[ROL02]

Update Client [CR08]

Acknowledgement [CR09]


Audit Record [AR02]

Client Registry Notification Consumer[ROL28]


HIX[ROL13] Client Update Notif. [CR10]

Figure6-Updateclient[CR08]invocationpattern

Theupdatenewclientoperation[CR08]providesthefunctionalityofupdatinganexistingclientrecord.Anupdatemaybeademographicupdatetoclientinformation,ormaybeamerge/unmerge(i.e.:MosahasjustbeenregisteredintheHIVregistry,herIDforthisregistryis567).Theclientregistryshouldgenerateanotification[CR10]thatclientinformationhasbeenupdated,andshouldsubmitthistothe340


HIX[ROL13](similartotheaddoperation).Theoperationshouldacknowledge[CR09]theupdateassucceedingorfailing.

CandidateSoftwarePackagesThefollowingsoftwarepackageswereidentifiedasbeingpotentialcandidatesforaClientRegistryserviceproviderimplementation.

• OpenMRS(http://openmrs.org)• OpenDM-MI(http://java.net/projects/open-dm-mi)• OpenEMPI(https://www.projects.openhealthtools.org/sf/go/page1038)• MohawkCollegeClientRegistryRI1(http://wiki.marc-hi.ca/Demonstration_Servers/MARC-

HI_Client_Registry)350• MirthMatch(http://www.mirthcorp.com/products/mirth-match)

Theanalysisoftheseprojectsisrelatedonlytotheirabilitytoperformtheoperationsidentifiedfortheclientregistry.

Candidate/FunctionMapThefiveidentifiedsoftwarepackageswereinvestigatedfortheircapabilitytosupporttheidentifiedoperationsofaclientregistryserviceprovider[ROL01].TheresultsofthisanalysisareoutlinedinTable2.Theresultsofthisanalysisdonotincludethefutureenhancementsorfeaturesonaroadmap.

Table2-ClientRegistryFunctionalSupport

Mirth OpenMRS DM-MI OpenEMPI MohawkCRCR01–ResolveIdentifier * * * X XCR03–DemographicsQuery * X * X XCR05–RegisterClient * X * X XCR08–UpdateClient * X * X XCR07–NewClientNotification X CR10–UpdateClientNotification

X

AR01†–AuditDisclosure X X ? X XAR02†–AuditRecord ? X ? X XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments

Sincetheserviceroleimplementationswillbeinteractingwithinservicesbasedmodel,theanalysisof360thefunctionalitytheyprovideisbasedsolelyontheexposedfunctions.

1TheMohawkCRRIiscurrentlyaveryearlystagesoftwareandwasincludedforacademicinterest.


TheanalysisofMirthMatchwasdifficultasthemajorityofwikipagesweren’tcomplete,anddocumentationwassparse.SinceMirthMatchisareferenceimplementationofHSSPIXS(formerlyEIS)theanalysisofthecapabilitiesofMirthMatcharebasedonIXSsupport.IXSsupportsequivalentfunctionsofthequeriesidentified[CR01,CR03]aswellasregistrationandupdate[CR05,CR08].TheIXSstandardhasnoidentifiednotificationmechanisms2.ItisalsoimportanttonotethatentitytraitswouldneedtobesetupinorderforMirthMatchtosupportdataelementsidentifiedfortheclientregistry.

TheanalysisofOpenMRSshowedthatitsupportedthestorageandretrievalofdemographicinformationrelatedtothepatient[CR03,CR05,CR08].Thesoftwareiscapableofstoringmultipleidentifiersforonepatientrecord3andiscapableofbeingusedforresolution[CR01],howeverexecuting370the“GET”patientbyalternateidentifier(nottheOpenMRSUUID)functionalityisunclear.Documentationrelatedtothesupportfornotificationsofpatientupdatesina“push”or“broadcast”mechanism[CR07,CR10]couldnotbelocated..

OpenDM-MI(MasterIndex)isagenericservicethatcanbeusedtomodelindicesforprettymuchanydomain.DM-MIwasfoundtosupportthemajorityofoperationsrequiredtofunctionasaclientregistry[CR01,CR03,CR05,CR08],howevercustomizationwouldberequired(asDM-MIisagenericproduct)andthesefunctionsaremarkedaspartial.ItwasalsonotapparentifDM-MI’ssoftwaresupportsbroadcastupdatenotifications[CR07,CR10].

OpenEMPIisbuiltaspartoftheOpenHIEprojectonOpenHeathTools(OHT).OpenEMPIwasfoundtosupportandexposethenecessaryfunctionalitytofullyimplementtheclientregistryservicerole“outof380thebox”[CR01,CR03,CR05,CR08,CR07,CR10].

TheclientregistryreferenceimplementationasdevelopedbyMohawkCollegerepresentsareferenceimplementationofhowanHL7v3clientregistryshouldfunction.Althoughtheregistrysupportstheresolution[CR01],maintenance[CR05,CR08]andsearch[CR03]ofclients,itdoesnotcurrentlysupportnotificationofclientupdates[CR07,CR10].

Auditingoftheaccessanddisclosureofclientdemographicinformationappearstobesupportedinmostoftheidentifiedsoftwarepackages(althoughnotnecessarilytoafederatedauditrepository).

CandidateSuitabilityBasedontheanalysisofthecandidatesoftware,thefollowingpackageshavebeenidentifiedassuitable(orpluggable)optionsforaclientregistrybasedontheoperationsidentified:390

• OpenEMPI–Fullysupportsthenecessaryfunctionalityforclientresolution,demographicquery,registration,updateandnotificationwithoutmodification.

2OMG,IdentityCross-ReferenceService(IXS),2011p.493OpenMRS,“OpenMRSDataModel,”https://wiki.openmrs.org/download/attachments/589829/Openmrs_data_model_1.6.png.


Thefollowingpackageshavebeenidentifiedasplausibleoptionsforclientregistryifmodificationsareperformed:

• OpenMRS–Supportsthenecessaryfunctionalityforclientdemographicquery,registration,andupdatewithoutmodification.DoesnotseemtosupporttheretrievalofaPatientresourcebyalternateidentifiers(onlybyUUID),modificationsmustalsobeperformedtoprovideupdatenotificationstoothersystemsinthesystem.

• MirthMatch–Supportsthenecessaryfunctionalityforclientregistrysuchasresolution,demographicquery,registrationandupdate.Requiresthesetupoftraitsforentities,andwould400requireadditionallogictointegratenotificationsandstructuredaudits4.

• OpenDM-MI–LikeMirthMatch,supportsthenecessaryfunctionalitytofacilitateclientregistryfunctionssuchasresolution,demographicquery,registrationandupdate.LikeMirthMatch,requiressetupofentitydefinitions,andwillrequireadditionallogicfornotificationandaudit.

• MohawkCR–Supportsthenecessaryfunctionalityforclientresolution,demographicquery,registrationandupdatewithoutmodification.Itdoesnotsupportnotificationofclientchangesandiscurrentlyinearlydevelopment.

ProviderRegistryTheproviderregistryserviceisresponsibleforthemaintenanceofproviderdatasuchasname,rolewithinthehealthcaresystem,address,etc…410

Atminimum,softwareactingasaproviderregistryshouldbecapableofsearchingprovidersbydemographicinformation(names,roles,address,etc…).Sincetheproviderregistryisafederatedservice,itmustsupporttheconceptofmultipleidentifiersforoneprovider.

RolesTherearethreerolesidentifiedfortheproviderregistryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.

• ProviderRegistryServiceProvider[ROL03]–Asystemimplementingaproviderregistryserviceproviderisresponsibleforthemaintainingthedemographic,roleandidentifierinformationrelatedtoaprovider.420

• ProviderRegistryServiceConsumer[ROL04]–Asystemimplementingaproviderregistryserviceconsumeriscapableofinvokingoperationsonafederatedproviderregistryservice.

• ProviderRegistryServiceNotificationConsumer[ROL29]–Asystemimplementingtheproviderregistryservicenotificationtargetroleiscapableofprocessingproviderregistrynotifications.

4Mirth,"eMPIRequirementFeedback,"http://www.mirthcorp.com/community/wiki/display/EIS/eMPI+Requirement+Feedback.


IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheProviderRegistry.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithPRwhichisusedtounambiguouslyidentifytheoperation.

ResolveIdentifier[PR01]

Provider RegistryService Supplier

[ROL03]

Provider Registry Service Consumer

[ROL04]

Resolve Identifier [PR01]

Resolve Resp. [PR02]

Figure7-Resolveprovideridentifier[PR01]invocationpattern430

Theresolveprovideridentifieroperation[PR01]isusedtoresolvealocalprovideridentifierwithoneofthefederatedproviderrecordsintheregistry.Forexample,NurseJoshuamaybeidentifier1255intheTBregistry,and6432inthelocalhospitalsystem.TheproviderregistryisresponsibleforrelatingJoshuatoboth(ormore)oftheseidentifiers.

Theresultofthisoperation[PR02]isamessagethatcontainsacompleteproviderdemographicrecord,andtherespectiveidentifiersfortheprovider.

ProviderQuery[PR03]


[ROL03]


[ROL04]

Provider Query [PR03]

Query Resp. [PR04]

Figure8-Providerquery[PR03]invocationpattern440

Thelookupproviderdemographicinformationoperation[PR03]isresponsibleforfetchingaprovider’sdemographicinformationbasedonthesupplieddemographic(name,gender,andaddressatminimum),androle(specialty,license,andstatusatminimum)parameters.Theresultoftheoperation[PR04]isalistofmatchingprovidersandtherolesthatthoseprovidersplay(orcanplay)withinahealthcarescenario.

Thisinformationmaybestoredindiseasespecificregistries(forexample,aTBprogrammeregistry).Thefederatedproviderregistryshouldmaintainanaggregateoftherolesthataparticularprovidercanplayacrosstheentireenterprise.


RegisterProvider[PR05]


[ROL03]


[ROL04]

Register Provider[PR05]

Acknowledgement [PR06]

HIX[ROL13]



Audit Record [AR02]

Provider Registry Notification Consumer[ROL29]

New Provider Notif. [PR07]

450

Figure9-Registerprovider[PR05]invocationpattern

Addnewprovideroperation[PR05]allowsnewprovidersandrolesplayedtoberegisteredwiththeproviderregistry.Itispossiblethatthe“new”providerismerelyanewpointeraproviderthatalreadyexistswithinanotherregistryorsystem.Theoperationofaddinganewproviderwillresultinanewlocalidentifier(localtotheproviderregistry)beinggenerated.Theresultoftheaddprovideroperationisanacknowledgementthatindicatesiftheoperationwassuccessful[PR06].

Sincetheproviderregistryparticipatesinasystem(ratherthanstandalone),andwillbeprimarilymaintainedbyprovidermanagers(likeCHWManagers)whichmaybesubjecttocorrections,thePRshouldprovideanotification[PR07]totheHIX[ROL13]thatanewproviderhasbeenadded.Thisnotificationmustincludethedemographicandroleinformationthatwassuccessfullyregisteredwithin460theproviderregistryservicerole.

ThesequenceforthisoperationisthesameasthesequenceforclientregistrynotificationsillustratedinFigure5onpage16.


UpdateProvider[PR08]


[ROL03]


[ROL04]

Update Provider [PR08]

Acknowledgement [PR09]

HIX[ROL13]



Audit Record [AR02]

Provider Registry Notification Consumer[ROL29]

Update Provider Notif. [PR10]

Figure10-Updateprovider[PR08]invocationpattern

Theupdateprovideroperation[PR08]providesthefunctionalityofupdatinganexistingprovider’sdemographicorroledata.Anupdatemaybeademographic/roleupdatetoproviderinformation,ormaybeamerge/unmergeofidentifiers(i.e.:Joshua’sidentifierfortheTBprogrammewasmisidentifiedandhasbeencorrected).Theproviderregistryshouldgenerateanotification[PR10]thatprovider470informationhasbeenupdated/correctedandnotifytheHIX(similartotheaddoperation)andshouldacknowledge[PR09]theupdateassucceedingorfailing.

CandidateSoftwareThefollowingsoftwarepackageswereidentifiedascandidatesforactingasaproviderregistry:

• OpenMRS(http://openmrs.org)• OpenDM-MI(http://java.net/projects/open-dm-mi)• MirthMatch(http://www.mirthcorp.com/products/mirth-match)• NexJProviderRegistry(https://www.projects.openhealthtools.org/sf/go/doc1661?nav=1)

Theanalysisoftheseprojectsisrelatedonlytotheirabilitytoperformtheoperationsidentifiedfortheclientregistry.Analysisonthedatarequirementsandcommunicationsinterfacescanbefoundinlater480sectionsofthisdocument.

Candidate/FunctionMapThefouridentifiedcandidatesoftwarepackageswerematchedagainstthefunctionalityoftheproviderregistry.TheresultsofthisanalysisareoutlinedinTable3.Theanalysisofeachoperationisbasedsolelyontheproduct’sabilitytoexposetheoperationtothirdpartyconsumers.Notethatonlycurrently


documentedfeatureswereincludedinthisanalysis,futurefeaturesorfunctionalityonroadmapswasnotconsidered.

Table3-ProviderRegistryFunctionalSupport

OpenMRS DM-MI Mirth NexJPRPR01–ResolveIdentifiers * * * XPR03–ProviderQuery X * * XPR05–RegisterProvider X * * XPR08–UpdateProvider X * * XPR07–NewProviderNotification PR10–UpdatedProviderNotification AR02†–AuditRecord X ? ? X–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisofOpenMRSinthePRrolerevealedthatithassupportforthemajorityoffunctionalityaPR490wouldneed.OpenMRSexposesa“User”objectthathasdemographicattachedviaaPersonrelationship.Thesoftwarealsohastheabilitytoassigneachproviderarole.Thismakesitpossibletomaintainproviderdemographicandroleinformation[PR05,PR08],andsearchproviderdemographicsbasedonthesecriteria[PR03].OpenMRSalsoappearedtoaudittheregistrationofusers[AR02],thoughtheseauditswerenotsenttoafederatedrepository.Supportforresolvingprovideridentifiers[PR01]wasmissingasitappearsthatalternateprovideridentifiersarenotmaintainedbyOpenMRS’UserorPersonclasses.

AswiththeClientRegistryanalysis,DM-MIprovidesthenecessaryfunctionalitytocustomizeitintofulfillingaPRservicerole.TheDM-MIsoftwarepackagesupportsthecreationofrecordsintheMasterIndex(MI)[PR05,PR08]andsupportsqueryingbasedonidentifyingtraits[PR01,PR03].Itwasnot500clearlyspecifiedintheDM-MIdocumentationiftheactofrecordinginformationresultedinanaudit[AR02].

MirthMatchisareferenceimplementationofOMGISXwhich,likeDM-MI,allowsforthedefinitionofentitytraitswhichcanberecordedand/orstored[PR05,PR08]andsubsequentlyqueried[PR01,PR03].MirthMatchcanthereforebecustomizedtosupportthePRservicerole.AswithDM-MI,nodocumentationsurroundingaudits[AR02]wasfoundinMirthMatchdocumentation(althoughdisclosuresareaudited)

AnalysisoftheNexJPRrevealedthatitisareferenceimplementationofthepan-CanadianHL7v3providerregistrymessages.Theregistrysupportsthemaintenanceofproviderdemographicandroledata[PR05,PR08]usingAddProviderandUpdateProvidermessages.TheNexJPRalsosupportsbasic510matchingofproviders[PR03]andsupportstheconceptoflocatingandstoringalternateidentifiers[PR01].Theregistrydoesnotappeartosupportstructuredtheauditingofrecordevents[AR02].


Noneoftheregistriesanalyzedsupportedtheconceptofnotifyingotherapplicationsofupdates/additionstotheproviderregistry[PR07,PR10].Thismaybeduetotherelativelylowimportanceofthisfeature(asonlyfederatedserviceswouldrequireit),orthattheproductshavenotyetimplementedthisfunctionality.

CandidateSuitabilityBasedontheanalysisofthecandidatesoftware,nopackageshavebeenidentifiedascompletelysuitedforproviderregistrybasedontheoperationsdefinitionsidentified.Thefollowingcandidatepackagesareplausibleoptionsforproviderregistrywithmodifications(intermsofoperationsupport):520

• OpenMRS–Supportsthenecessaryfunctionalityforproviderdemographicandrolesquery,registration,andupdatewithoutmodification.DoesnotseemtosupportresolutionofprovideridentifiersasitappearstostoreonlyoneUUIDperuserrecord,modificationsmustalsobeperformedtoprovideupdatenotificationstoothersystemsinthesystem.

• MirthMatch–Supportsthenecessaryfunctionalityforproviderregistrysuchasresolution,demographicandrolequery,registrationandupdate.Requiresthesetupoftraitsforproviderentities,andwouldrequireadditionallogictointegratenotificationsandstructuredaudits.

• OpenDM-MI–LikeMirthMatch,supportsthenecessaryfunctionalitytofacilitateproviderregistryfunctionssuchasresolution,demographic/rolequery,registrationandupdate.LikeMirthMatch,requiressetupofentitydefinitions,andwillrequireadditionallogicfornotification530andaudit.

• NexJPR–Supportsthenecessaryfunctionalityforproviderresolution,demographic/rolequery,registrationandupdatewithoutmodification.Itdoesnotsupportnotificationofproviderupdatesandcurrentlydoesnothaveanyfacilitiesforstructuredaudits(ascanbeseenindocumentation).

FacilityRegistryThefacilitiesregistryisresponsibleforthemaintenanceandsearchoffacilities(servicelocations)withinthesystem.Facilitiesdataincludesattributessuchasname,physicallocations,offeredservices,contactinformation,etc..

Atminimumthefacilitiesregistryshouldsupportsearchingfacilitiesbyname,serviceofferedand540physicallocation.Sincethefacilitiesregistryisafederatedservice,itshouldbecapableofstoringmultipleidentifiersforasinglefacility.

RolesTherearetworolesidentifiedforthefacilityregistryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.

• FacilityRegistryServiceProvider[ROL05]–Asystemimplementingafacilityregistryserviceproviderisresponsibleforthemaintainingtheregistrationdata,providedservices,andlocationinformationrelatedtoafacility.


• FacilityRegistryServiceConsumer[ROL06]–Asystemimplementingafacilityregistryservice550consumeriscapableofinvokingoperationsonafederatedfacilityregistryservice.

IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheFacilityRegistry.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithFRwhichisusedtounambiguouslyidentifytheoperation.

FacilityQuery[FR01]

Facility Registry Service Supplier

[ROL05]

Facility Registry Service Consumer

[ROL06]

Facility Query [FR01]

Query Response [FR02]

Figure11-Facilityquery[FR01]invocationpattern

Thefacilityqueryoperation[FR01]isresponsibleformatchingthelistoffacilitiesagainstthesuppliedqueryparameterssuchasfacilityname,servicesoffered,andaddressatminimum.Theresultofthequeryoperation[FR02]isalistoffacilitiesthatmatchedthequerycriteria.560

RegisterFacility[FR03]


[ROL05]


[ROL06]

Register Facility [FR03]

Acknowledgement [FR04]


Audit Record [AR02]

Figure12-Registerfacility[FR03]invocationpattern

Thefacilityregistrationoperation[FR03]permitstheregistrationofanewfacilitywithinthefacilityregistry.Theresultoftheoperationisanacknowledgement[FR04]indicatingwhethertheregistrationofthefacilitywassuccessful.

Itisassumedthattheregistrationofservicedeliverylocationswillbeperformedbyacentralauthorityresponsibleforthemaintenanceoffacilitieswithinajurisdiction.Forthisreason,thebroadcastingoffacilityregistrationisnotrequired.


UpdateFacility[FR05]570


[ROL05]


[ROL06]

Update Facility [FR05]

Acknowledgement [FR06]


Audit Record [AR02]

Figure13-Updatefacility[FR05]invocationpattern

Theupdatefacilityoperation[FR05]isusedtoupdatetheregistrationdata,servicesprovided,orplaces(orsub-locations)ofaparticularfacilitywithinthefacilityregistry.Theresultofthisoperationisanacknowledgement[FR06]indicatingiftheupdateoffacilityregistrationdatawassuccessful.

Similartothecreationofafacility,itisassumedthatclinicalregistrieswillrarelyneedto“correct”datarelatedtofacilityregistrationinformation.Therefore,theprocessofbroadcastinganupdatetotheHIXisomitted.

CandidateSoftwareThefollowingcandidatesoftwarewasidentifiedaspotentialsoftwareimplementationsofthefacilities580registry:

• OpenMRS(http://openmrs.org)• OpenDM-MI(http://java.net/projects/open-dm-mi)• MirthMatch(http://www.mirthcorp.com/products/mirth-match)• FRED1.0(http://facilityregistry.org)• MohawkServiceDeliveryLocationRegistry(SDLR)(NotYetAvailable)

Candidate/FunctionMapThefourcandidatesoftwarepackageswerematchedagainsttheoperationsidentifiedforthefacilityregistryservicerole,theresultsofthisanalysisisoutlinedinTable4.

Theanalysisofeachoperationisbasedsolelyoneachsoftware’sabilitytoexposetheoperationtothird590partyconsumers.Onlydocumentedfeaturesavailableinthecurrentreleasewereincludedinthisanalysis,futurefeaturesorfunctionalityonroadmapswasnotconsidered.


Table4-FacilityRegistryFunctionalSupport

OpenMRS DM-MI Mirth FRED MohawkSDLR

FR01–FacilityQuery X * * X XFR03–RegisterFacility X * * X XFR05–UpdateFacility X * * X XAR02–AuditRecord X ? ? X–Softwarepackagesupportsthenecessaryfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

TheanalysisofOpenMRSrevealedthatissupportsthenecessaryfunctionalitytosupporttheroleofafacilityregistry[ROL05].Itsupportstheregistration[FR03,FR05],andqueryoflocationdata[FR01]andprovidesendpointsforthisfunctionalityvia“Location”resourcesintheRESTAPI.

Asgenericdatamanagementsolutions,OpenDM-MIandMirthMatchcanbeconfiguredtosupporttheroleoflocationregistry[ROL05].Bothproductssupporttheconceptofregistration[FR03],update600[FR05]andquery[FR01]ofentities.Thedownsidetothesesoftwarepackagesisthatconfigurationofentitytraitsisrequiredbeforethesoftwarepackagescanberealizedasafacilityregistry.Itisalsounclearfromtheavailabledocumentation,iftheseproductsarecapableofgeneratingstructuredaudits.

TheMohawkSDLRisareferenceimplementationofalocationsregistryandsupportsthenecessaryfunctionalitytoregisterandmaintainfacilitydata[FR03,FR05]aswellasquerythoseregisteredfacilities(knownasservicedeliverylocationsintheproduct).

TheFREDRESTinterfaceisnotaproductperse,ratheranormalizedinterfacewhichcanbeimplementedbysoftwarevendors.Solutionsimplementingthisfunctionalitycanbeadaptedtofulfilltheroleoffacilityregistry[ROL05]astheinterfacedefinesregisterandmaintainfacilityfunctions[FR03,FR05].TheFREDinterfacealsodefinesagenericquerymechanism[FR01]which,whencombinedwith610theexternalidentifiersproperty,makesidentifierresolutionpossible.

Thespecificationusesshortnamestoidentifytheagencywhichcreatedaparticularexternalidentifierwhichmayleadtocollisionswhencrossingjurisdictionaland/orenterpriseboundaries.ThecoredatasetofFREDwillmostlikelyrequireextensiontoincludeattributessuchasservicesoffered,contactinformation,etc.

CandidateSuitabilityBasedontheanalysisofthecandidatesoftware,thefollowingpackageshavebeenidentifiedasimplementingthenecessaryoperationstoactasafacilityregistry:

• FRED–Supportsthebasicfunctionalityrequiredtooperateasafacilityregistry.Itprovidessufficientmechanismsforqueriesandidentityresolution.SoftwareimplementingtheFRED620servicesmayrequireimplementerstostandardizeonextendedattributesforusewithintheHIX,


andmayrequirestrictgovernanceovertherepresentationofalternateidentifierassigningauthorities.

• OpenMRS–Supportsthefunctionalityneededtooperateasafacilityregistry.Providesmechanismsforlocationqueries,registrationsandupdatesandperformsthenecessaryauditing.OnecaveatidentifiedwithOpenMRS,isthatthesoftwareappearstosupportonlyoneidentifierforfacilitieswhichmayaffectitssuitabilityinthisrolerelatedtoidentityresolution.

Thefollowingpackagescanactasafacilityregistry(fromafunctionalstandpoint)butrequireadditionalsetupand/ormodifications:

• MirthMatch–Supportsthenecessaryfunctionalityforfacilityregistrysuchasquery,630registrationandupdate.Requiresthesetupoftraitsforfacilityentities,andwouldrequireadditionallogictointegratestructuredaudits.

• OpenDM-MI–LikeMirthMatch,supportsthenecessaryfunctionalitytofacilitatefacilityregistryfunctionssuchasquery,registrationandupdate.LikeMirthMatch,requiressetupofentitydefinitions,andwillrequireadditionallogicforaudit.

• MohawkSDLR–Supportstherequiredoperationstoactasafacilityregistry,howeverlacksthecapabilitytoaudittherecordoffacilitychangesandwouldrequireadditionalcodetosupportthis.

TerminologyServicesTheterminologyregistryisresponsibleforthemaintenance,validation,mapping,queryandrelationof640codifiedconceptswithinthesystem.Sincethesystemisprovidingdatabetweenmanydifferentsoftwarepackages,thisserviceisperhapsthemostimportantofallthefederatedregistries/services.

Theterminologyregistrymaintainsamastersetofconceptsandprovidestheabilitytomapconceptsbetweendifferentcodificationsystems.Forexample,iftheSharedHealthRecordusestheICD-10-CMcodeZ33.1tosignifypregnancy,andaHospitalInformationSystem(HIS)ataregionalhospitalqueriesusingtheICD-9-CMcodeV22.2,thentheremustbeamechanismtoprovidevalidationandmappingbetweentothetworegardlessofthecodeusedtorecordthecondition.

RolesTherearetworolesidentifiedfortheterminologyregistryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthis650document.

• TerminologyServicesProvider[ROL07]–Asystemimplementingaterminologyservicesproviderisresponsibleforthemaintainingalllistofallconceptsusedwithinaparticularsystemaswellasmaintainingmapstoandfromcodeswithinvariouscodesystems.

• TerminologyServicesConsumer[ROL08]–Asystemimplementingaterminologyservicesconsumeriscapableofinvokingoperationsonafederatedterminologyservicesproviderforthepurposeofvalidation,mapping,and/orqueryofconcepts.


IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheterminologyservices.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithTRwhichisusedtounambiguouslyidentifytheoperation.660

ValidateCode[TR01]

Terminology Services Provider[ROL07]

Terminology Services Consumer[ROL08]

Validate Code [TR01]

Validation Result [TR02]

Figure14-Validatecode[TR01]invocationpattern

Thevalidatecodeoperation[TR01]providesvalidationfunctionalityforanycodedconceptinanycodesystemusedwithinaparticularjurisdiction.Theresultofthevalidationoperationisavalidationresult[TR02]containingthedetectedissuesfoundduringvalidation.

GetCodeDetails[TR03]



Get Details [TR03]

Concept Details [TR04]

Figure15-Getcodedetails[TR03]invocationpattern

Thegetconceptdetailsoperation[TR03]willperformalookupofaparticularconcept’sdetailsgiventhe670concept’scodeinoneofthesupportedcodesystems.Theresultofthemessageisthecompletedetails[TR04]oftheprovidedcodeincludingdisplayname,versioncode,andstatus(active,obsolete,etc…)atminimum.

TranslateCode[TR05]



Translate Code [TR05]

Code Translation [TR06]

Figure16-Translatecode[TR05]invocationpattern

Thetranslatecodeoperation[TR05]exposesthenecessaryfunctionalitytotranslateacodefromonecodificationsystemtoanother.Theserviceconsumer[ROL08]shouldbeexpectedtoprovidethecode,andcodesystemofthesourcemnemonicandthetargetcodesystematminimum.Theresultoftheoperationisastructure[TR06]thatdescribestheequivalentconcept(s)inthetargetcodificationsystem.680

CandidateSoftwareThefollowingcandidatesoftwarewasidentifiedforuseasaterminologyservicesprovider:

• OpenMRS(http://openmrs.org)


• ApelonDTS(http://apelon-dts.sourceforge.net)

Additionalcommercialsoftwarecandidateswereidentifiedbutwerenotincludedinthisanalysis.Thecommercialsoftwarepackagesidentified(butnotincludedinanalysis)are:

• 3MHealthDataDictionary(HDD)(http://solutions.3mcanada.ca/wps/portal/3M/en_CA/CA_HIS/Home/Products/All/Dictionary/)

• OceanTerminologyService(OTS)(http://www.oceaninformatics.com/solutions/knowledge_management)690

Candidate/FunctionMapBothofthecandidatesoftwarepackageswerecomparedagainsttherequiredfunctionalityandtheresultsaresummarizedinTable5.Unlikeothersub-systemanalysisperformedthatonlyprovidedanalysisoncurrentfunctionality,thisanalysisincludesfeaturestobeincludedinApelonDTS4.0whichisexpectedtobereleasedbythetimethisdocumentispublished(December2011).

Theanalysisofthesesystemsisbasedontheirabilityofthirdpartyapplicationtoinvokethemusingsomeformofmessaging(REST,SOAP,etc…)

Table5-TerminologyServicesFunctionalityMap

OpenMRS ApelonDTS3.5 ApelonDTS4.0TR01–ValidateCode * ? XTR03–GetCodeDetails X ? XTR05–TranslateCode ? XX–Softwarepackagesupportsthenecessaryfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisofOpenMRSrevealedthatconceptsdefinedwithinanOpenMRSinstancecanbequeried700[TR02]usingthe“Concept”resourcesontheRESTAPI,althoughthefunctionalityappearstobesplitintoseveraloperations.Codevalidation[TR01],althoughnotexplicitlysupported,canbeattainedthroughthegetconceptoperationcurrentlysupportedonOpenMRS.Unfortunately,nodocumentationcouldbefoundreferencingacapabilitytotranslatecodemnemonicsbetweencodificationsystems.

ApelonDTS3.5canbeaccessedbyexternalsystemsviaanHL7CommonTerminologyServices(CTS)wrapper,althoughlittledocumentationcouldbelocatedaboutthewrapperforDTS.HL7CTSprovidesthenecessaryinterfacestovalidate[TR01],fillincodedetails[TR03]andtranslate/mapcodes[TR05],howeverbecausenodocumentationordownloadoftheCTSwrappercouldbelocated,thesefunctionsareidentifiedas“notdocumented”inthecomparison.

ApelonDTS4.0supportsHL7CTS2.0interfacesandcustomweb-servicesinterfacestotheDTSAPI.710SincethecurrentDTSAPIprovidesthenecessaryfunctionalitytoquery[TR03]andmapconcepts[TR05],andHL7CTS2.0providesquery[TR03],mapping[TR05]andvalidation[TR01]operations,anApelonDTS4.0instancecanoperateasaterminologyrepository“outofthebox”.


CandidateSuitabilityBasedontheanalysisofthecandidatesoftware,thefollowingpackageshavebeenidentifiedasimplementingthenecessaryoperationstoactasaterminologyservicesprovider:

• ApelonDTS4.0–SupportsthefunctionalityneededtooperateasaterminologyregistryviatheHL7CTS2andDTSAPIinterfaces.AlthoughDTS4.0appearstosupportthenecessaryfunctionalityitiscurrentlynotavailableforpublicdownloadandreview,butisexpectedtobeavailablebythereleaseofthisdocument(December2011)720

Thefollowingpackagescanactasaterminologyservicesprovider(fromafunctionalstandpoint)butmayrequireadditionalsetupand/ormodifications:

• OpenMRS–Supportstheconceptofretrievingconceptdata.ThereareafewcaveatstousingOpenMRSasaterminologyservicesprovider,namelythatexplicit“validation”isnotsupportedandmayneedimplementedviathe“query”operation.Additionally,thereisnodocumentationsurroundingtheabilityofOpenMRStomapconceptsbetweenterminologies.

• ApelonDTS3.5–TheDTS3.5JavaandC#APIsbothsupportthenecessaryfunctionalitytoactasaterminologyrepository,howeverbecausetheseoperationsarenotreadilyconsumablebythirdparties(theyrequiredevelopmentofaweb-serviceswrapper,ortheCTSwrapper)itisnotidentifiedasasuitable“federated”terminologyservice.730

SharedHealthRecordTheSharedHealthRecord(SHR)isusedtodescribealogicalclinicalrepositorythatisresponsiblefortheaggregationofdatarelatedtopatientcareduringthelifetimeofapatient.SinceafullyspecifiedtheSHRispotentiallyhuge,onlytherolesandoperationsrequiredtofulfillthebusinessrequirementsfoundonpage9areidentifiedhere.

RolesTherearetenrolesidentifiedforthesharedhealthrecordservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.

• SharedHealthRecordServiceProvider[ROL09]–Asystemimplementingasharedhealth740recordserviceprovideriscapableofthestorage,maintenanceandqueryofpatientencountersandpatientcaredatarelatedtoapatient.

• SharedHealthRecordServiceConsumer[ROL10]–Asystemimplementingasharedhealthrecordserviceconsumeriscapableofinvokingcommandsagainstafederatedsharedhealthrecordserviceprovider[ROL09]toretrievedata.

• HealthConditionsRepositoryServiceProvider[ROL19]–Asystemimplementingahealthconditionsrepositoryserviceproviderroleisresponsibleforthemaintenanceandqueryhandlingofactiveandpasthealthconditionsforaparticularpatient.


• HealthConditionsRepositoryServiceConsumer[ROL20]–Asystemimplementingahealthconditionsrepositoryserviceconsumerroleisresponsibleforinvokingservicesontheprovider750[ROL19]tosharehealthconditions.

• ReferralRepositoryServiceProvider[ROL21]–Asystemimplementingareferralrepositoryserviceproviderroleisresponsibleforthemaintenanceandqueryofclinicalreferralinformationrelatedtoaparticularpatient.

• ReferralRepositoryServiceConsumer[ROL22]–Asystemimplementingareferralrepositoryserviceconsumerroleisresponsibleforinvokingservicesontheprovider[ROL21]tosharereferraldata.

• ObservationsRepositoryServiceProvider[ROL23]–Asystemimplementinganobservationsrepositoryserviceproviderroleisresponsibleforthemaintenanceandqueryofobservationsrecordedaboutapatient.760

• ObservationsRepositoryServiceConsumer[ROL24]–Asystemimplementinganobservationsrepositoryserviceconsumerroleisresponsibleforinvokingservicesontheprovider[ROL23]toshareobservations.

• EncounterRepositoryServiceProvider[ROL25]–Asystemimplementinganencounterrepositoryserviceproviderroleisresponsibleforthemaintenanceandqueryofclinicalencountersthatoccurbetweenaproviderandaclient.

• EncounterRepositoryServiceConsumer[ROL26]–Asystemimplementinganencounterrepositoryserviceconsumerroleisresponsibleforinvokingservicesontheprovider[ROL25]toshareencounterdata.

• CarePlanRepositoryServiceProvider[ROL30]–Asystemimplementingacareplanrepository770serviceproviderroleisresponsibleforthemaintenanceandqueryofcareplansrelatedtopatients.Careplansusuallyresultinaseriesof“future”encounters(appointments)orstepstoprovidecare.

• CarePlanRepositoryServiceConsumer[ROL31]–Asystemimplementingancareplanrepositoryserviceconsumerroleisresponsibleforinvokingservicesontheprovider[ROL30]toshareencounterdata.

Itisexpectedthatmanyjurisdictionsmaychoosetodeploymanydifferentsoftwarepackagesastheir“sharedhealthrecord”(forexample:areferralrepository,anobservationsrepositoryandaHIVregistry).Thisdeploymentsscenarioiswhathasdriventhedecisiontosplitthesharedhealthrecordroleintomoregranulardefinitions.780

IdentifiedOperationsThefollowingoperationshavebeenidentifiedforthesharedhealthrecord.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithSHRwhichisusedtounambiguouslyidentifytheoperation.


RecordClinicalObservation[SHR01]

Observation Repository Service

Provider[ROL23]


Consumer[ROL24]

Record Obs. [SHR01]

Acknowledgement [SHR02]


Audit Record [AR02]

Encounter Repository Service Provider

[ROL25]

Update Enc. [SHR13]

Figure17-Recordclinicalobservation[SHR01]invocationpattern

Therecordclinicalobservation[SHR01]operationisusedbyconsumerapplicationstorecordaclinicalobservation(s)relatedtoapatient.Thisoperationshouldexpectobservationvalue,type,interpretation790andtimeasdataelementsatminimum,andwillacknowledge[SHR02]thecallerindicatingwhethertheoperationwassuccessful.

Theprocessofobservingusuallyoccurswithinthecontextofanencounter.Therecordobservation[SHR01]operationshouldprovideamechanismforlinkinganobservationwithanencounter[SHR13]whichwillresultintheappropriateoperationbeingcalled.Iftheencounterrepository[ROL25]andobservationrepository[ROL23]areimplementedwithinthesamesoftware,messagingdoesnotneedtobeusedbetweencomponents.

Theactofrecordinganobservationwillresultinanaudit[AR02].


QueryClinicalObservation[SHR03]


Provider[ROL23]


Consumer[ROL24]

Query Obs. [SHR03]

Obs. List [SHR04]



800

Figure18-Queryclinicalobservation[SHR03]invocationpattern

Thequeryclinicalobservation[SHR03]operationallowscallerstosolicitalistofobservationsfromtheobservationrepository(orSHR)basedontheirtype,client,encounter,andtimeatminimum.Theresultofthissolicitationisalistofobservations[SHR04]matchingthequerycriteria.

TheactofdisclosingPHItoacallerwillresultinanaudit[AR01]beinggenerated.

RecordHealthCondition[SHR05]

Health Conditions Repository Service

Provider[ROL19]


Consumer[ROL20]

Record HC [SHR05]



Audit Record [AR02]

Figure19-Recordhealthcondition[SHR05]invocationpattern

Therecordhealthconditionoperation[SHR05]registersanewhealthconditionwiththehealthconditionrepository.Informationrelatedtothehealthconditiontype,time,anddiagnosingprovider810shouldbeexpectedbytheoperation.Theresultofthisoperationisanacknowledgementindicatingwhethertheregistrationofthehealthconditionwassuccessful.


UpdateHealthCondition[SHR07]


Provider[ROL19]


Consumer[ROL20]

Update HC [SHR07]



Audit Record [AR02]

Figure20-Updatehealthcondition[SHR07]invocationpattern

Sincehealthconditionsaredynamicandlongrunningrecords,afacilitymustexisttoupdateexistingconditionstatus,severity,relatedrecords.Thisisthepurposeoftheupdatehealthcondition[SHR07]operation.Thisoperationwillupdatearegisteredhealthconditionwithnewinformation.Theresultofthisoperationisanacknowledgement[SHR08]indicatingwhetherornotanewversionwascreatedforthehealthcondition.820

Note:InformationMUSTneverbereplacedordeleted;theupdateoperationisan“AddNewVersion”operation.

QueryHealthConditions[SHR09]


Provider[ROL19]


Consumer[ROL20]

Query HC [SHR09]

HC List [SHR10]



Figure21-Queryhealthconditions[SHR09]invocationpattern

Thequeryhealthconditionsoperation[SHR09]willquerytheavailablehealthconditionsforaparticularclientbasedonconditiontype,status,andseverityatminimum.Theresultofthequeryisalistofallhealthconditionsthatmatchthespecifiedquerycriteria.

Thedisclosureofthehealthconditiontothecallerwillresultinanaudit[AR01]ofthedisclosureevent.


RecordClinicalEncounter[SHR11]830


[ROL25]

Encounter Repository Service Consumer

[ROL26]

Record Enc. [SHR11]



Audit Record [AR02]

Referral Repository Service Provider

[ROL21]

Fulfill Ref. [SHR25]

Figure22-Recordclinicalencounter[SHR11]invocationpattern

Therecordclinicalencounteroperation[SHR11]willopenanewclinicalencounterwithintheencounterrepository[ROL25].Theresultofthismessageisanacknowledgement[SHR12]thatidentifieswhethertherecordoperationwassuccessful.

Sinceanencountermaybeexecutedinordertofulfillareferral,theencounterrepository[ROL25]maychoosetoexecutethefulfillreferral[SHR25]operationagainstthereferralrepository(or,iftheencounterrepository[ROL25]isalsothereferralrepository[ROL21]thenmerelylinktherecords).

UpdateClinicalEncounter[SHR13]


[ROL25]


[ROL26]

Update Enc. [SHR13]



Audit Record [AR02]

840

Figure23-Updateclinicalencounter[SHR13]invocationpattern


Theupdateclinicalencounter[SHR13]operationcreatesanewversionoftheclinicalencounterwithintheencounterrepository[ROL25].Theupdateclinicalencounteroperationwillallowcallerstoupdateinformationabouttheencounter,ortoassociatenewclinicaldatawiththeencounter.Theresultoftheupdateoperationisanacknowledgement[SHR14]whichconveyswhetherornottheupdateoperationwassuccessful.

QueryClinicalEncounters[SHR15]


[ROL25]


[ROL26]

Query Enc. [SHR15]

Enc. List [SHR16]



Figure24-Queryclinicalencounters[SHR15]invocationpattern

Thequeryclinicalencounters[SHR15]operationwillsearchtheencounterrepository[ROL25]forclinical850encountersthematchthespecifiedcriteria.Atminimum,thesearchoperationshouldpermitfilteringbasedonencountertype,starttime,andstatus.Theresultofthequeryoperationisalist[SHR16]ofallencountersthatmatchthespecifiedcriteria.

AswithalldisclosureofPHI,thequeryclinicalencounteroperation[SHR15]willresultinanauditofdisclosure[AR01]


RecordCarePlan[SHR17]

Care Plan Repository

Service Provider

[ROL30]

Care Plan Repository

Service Consumer

[ROL31]

Register CP [SHR17]


Audit Repository

[ROL15]

Audit Record [AR02]

Encounter Repository

Service Provider

[ROL25]

Schedule Appts. [SHR11]

Figure25-Recordcareplan[SHR17]invocationpattern

Therecordcareplanoperation[SHR17]willresultinthecreationofacareplaninthecareplanrepository[ROL27].Thecreationofacareplanwillnotonlyresultinanaudit[AR02],butmayresultina860schedulingofappointments(orencounterswithafuturedate)[SHR11]andadditionalprocessing.Theprocessingthatoccursdependswhollyonthetypeofcareplancreated.Theresultoftheoperationisanacknowledgement[SHR18]thatindicatesiftherecordwassuccessful.

QueryCarePlan[SHR19]

Care Plan Repository Service Provider

[ROL30]

Care Plan Repository Service Consumer

[ROL31]

Query CP [SHR19]

CP List [SHR20]



Figure26-Querycareplan[SHR19]invocationpattern


Thequerycareplan[SHR19]operationisintendedtosupportthequeryofexisting,activecareplanssotheconsumercandetermineadherence,ornextsteps.Theresultofthequerycareplan[SHR19]messageisalistofactivecareplans[SHR20].

GetClinicalSummary[SHR21]870

Shared Health Record Service

Provider[ROL09]

Shared Health Record Service

Consumer[ROL10]

Get Summary [SHR21]

PHI Record List [SHR22]




Provider[ROL19]


[ROL21]

Observations Repository Service

Provider[ROL23]


[ROL25]

Query Obs. [SHR03]

Query Enc. [SHR15]

Query Ref [SHR27] Query HC [SHR09]

Figure27-Getclinicalsummary[SHR21]invocationpattern

Thegetclinicalsummaryoperation[SHR21]isanaggregationfunctionofthesharedhealthrecordrepository[ROL09].ThepurposeofthisoperationistoaggregateallclinicalrecordsfromanyimplementedservicerolesintheSHRintoasinglelistofpatientrecords[SHR22].

Theoperationdiagramillustratesacalltovariousserviceroles[ROL19,ROL21,ROL23,ROL25],howeveritisexpectedthataSHR[ROL09]willimplement(oract)asoneormoreoftheseroles.Ifthisisthecasethenlocaldatabaselookupssufficeforthepurposeofaggregation.

ItisnotrequiredtheSHR[ROL09]contactexternalregistriesusingmessagingtoaggregateclinicaldata,asthisisthepurposeoftheHIX’sorchestrationservice[ROL13].880


RecordReferral[SHR23]


[ROL21]

Referral Repository Service Consumer

[ROL22]

Record Ref. [SHR23]



Audit Record [AR02]

Figure28-Recordreferral[SHR23]invocationpattern

Therecordreferraloperation[SHR23]isresponsiblefortheregistrationofnewreferralsinthereferralrepository[ROL21].Dataelementsrelatedtothereferralincludestatus,targetprovider/facility,reasonandnote.Theresultoftherecordoperationisanacknowledgement[SHR24]thatindicateswhethertherecordofthereferraldatawassuccessful.

FulfillReferral[SHR25]


[ROL21]


[ROL22]

Fulfill Ref. [SHR25]



Audit Record [AR02]

Figure29-FulfillReferral[SHR25]invocationpattern890

Thereferralfulfillmentoperation[SHR25]isaspecializedupdateoperationthatmarksthereferralasfulfilledandlinksthereferraltotheencounterthatfulfillsthereferral.Theresultofthisoperationisanacknowledgement[SHR26]whichindicateswhetherthefulfillmentofthereferralrecordwassuccessful.


QueryReferral[SHR27]


[ROL21]


[ROL22]

Query Ref. [SHR27]

Ref. List [SHR28]



Figure30-QueryReferral[SHR27]invocationpattern

Thequeryreferraloperation[SHR27]isresponsibleforthequeryofreferraldatathatiscurrentlycontainedwithinthereferralrepository[ROL21]thatmatchesthespecifiedqueryparameters(status,type,destination,andfulfillmentstatusatminimum).Theresultofthequeryisalistofreferrals[SHR28]thatmatchthespecifiedquerycriteria.900

CandidateSoftwareThefollowingsoftwarepackageswereidentifiedascandidatesforsharedhealthrecordimplementations:

• CommCareHQ(http://CommCareHQ.org)• OpenMRS(http://openmrs.org)• MARC-HISHR(http://wiki.marc-hi.ca/Demonstration_Servers/MARC-HI_Shared_Health_Record)

Inadditiontotheseez-HISwasidentifiedasacandidateforasharedhealthrecord,howevertheanalysisonthissoftwarewasverylimitedasnoEnglishlanguagedocumentationwasfound(http://ezvida.com.br).

Candidate/FunctionMap910Thecandidate/functionmapfortheSHRisslightlymorecomplexthantheotherservicerolesidentifiedinthisspecification.BecausesoftwarepackagescanprovidepartialfunctionalityofthefullSHRrequiredbytheBusinessRequirementsforthisdocumenttheanalysishasbeensummarizedbyrole.

Theanalysisofeachofthesepackageswasperformedbasedonthedocumentationrelatedtothecurrentcapabilityoftheoriginalsoftwarepackage(the“trunk”version),andthesoftwarepackage’sabilitytoexposetheoperationstothirdpartyapplications.Forsummarypurposes,theresultsofanalysisperSHRrolearelistedinTable6.


Table6-FunctionalityMapforallSHRServiceRoles

CommCareHQ OpenMRS MARC-HISHRROL09–SharedHealthRecordServiceProvider * X XROL19–HealthConditionsRepositoryProvider * XROL21–ReferralRepositoryServiceProvider * XROL23–ObservationsRepositoryServiceProvider * X XROL25–EncounterRepositoryServiceProvider * * *ROL27–CarePlanRepositoryServiceProvider X–Softwarepackagesupportsthenecessaryfunctionality*-Potentialcaveatsoradditionalcustomizationmaybeneeded920

Thefirstroletobeanalyzedwasthatofthesharedhealthrecordproper[ROL09].Thisanalysisprovidesanoverviewofthetotalfunctionalitythateachpackageprovides.Forexample,ifapackagesupportsgetsummary[SHR21],andothers[SHR03,SHR15]thismeansthatthepackagecanactasanaggregatedatafeedforencountersandobservationsasonesystem.

TheresultsoftheanalysisoftheSHRrole[ROL09]havebeensummarizedinTable7.

Table7-FunctionalityMapforSharedHealthRecord[ROL09]

CommCareHQ OpenMRS MARC-HISHRSHR21–GetClinicalSummary X X XSHR15†-QueryClinicalEncounters * X SHR03†–QueryClinicalObservations * X XSHR27†-QueryReferrals * XSHR09†-QueryHealthConditions * XAR01–AuditDisclosure X X XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisofCommCareHQrevealedthatitwaspossibletorequestasummaryofinformationfromthesystem[SHR21]howeveritappearsthatthisoperationisprimarilyintendedasadataextract5ratherthantransactional“invoke”ofanoperation.Furtheranalysisrelatedtoeachofthedatatypescollected930byCommCareHQarediscussedinmoredetaillaterinthissection.SupportforqueryingismarkedaspartialasitcouldnotbedeterminedifqueryparameterscanbesuppliedtotheexportAPIforserversidefiltering.CommCareHQprovidesaworkermonitoringmodule6whichauditsthedisclosureofhealthinformationperHIPAA.

5Dimagi,"ExportAPI,"https://confluence.dimagi.com/display/commcarepublic/Export+API.6Dimagi,"WorkerMonitoring,"https://confluence.dimagi.com/display/commcarepublic/Worker+Monitoring.


OpenMRSisabletocompileanaggregatesummary[SHR21]foraparticularpatientusingdatathatitsupports(inthecontextofthisspecification,observationsandreferrals).OpenMRSauditsthedisclosureofdata[AR01]inastructuredform(althoughitdoesnotappeartosendauditstoafederatedauditrepository).

TheMARC-HISHRisareferenceimplementationofthepan-Canadianmessagingspecificationwhichidentifiesthefunctionalitynecessaryforcompilingaclinicalsummary[SHR21]foraparticularpatient.At940thistime,itappearsthatobservations,referralsandhealthconditionsareincludedintheclinicalsummariesforpatients.TheMARC-HISHRalsoauditsdisclosures[AR01]toafederatedauditrepository.

AnalysisforsuitabilityasanimplementationofahealthconditionrepositoryhasbeensummarizedinTable8.

Table8-FunctionalityMapforHealthConditionsRepositoryRole[ROL19]

CommCareHQ OpenMRS MARC-HISHRSHR05–RecordHealthCondition X XSHR07–UpdateHealthCondition X XSHR09–QueryHealthConditions * XAR01–AuditDisclosure X X XAR02–AuditRecord X X XX–Softwarepackagesupportsthenecessaryfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisofCommCareHQrevealedthatitscasemanagement“create”and“update”operationsprovidesufficientequivalencytorecordhealthconditions[SHR05]andupdatehealthconditions[SHR07]respectively..Itwasdeterminedthatusingthe“create”and“update”operationsonthecaseXMLAPIresultsinaudits[AR02].ItispossibletousetheexportAPIprovidedwithinCommCareHQtofulfill950portionsofthequeryhealthconditions[SHR09],howeverittheabilitytosupplyqueryfilterstotheexportAPIcouldnotbedetermined(thereasonforpartialfunctionalsupportbeingmarked).

OpenMRSdidnotappeartoprovideanendpointinterfaceforinvokingtherecord,updateorquery[SHR05,SHR07,SHR09]operations,andwasdeterminednottosupportthesefunctions.

TheMARC-HISHRreferenceimplementationsupportsthenecessaryfunctionalitytorecord,updateandqueryhealthconditions[SHR05,SHR07,SHR09]andauditsthedisclosureandcreationofdata[AR01,AR02]

Thereferralrepositoryserviceprovider[ROL21]analysisforsuitabilityhasbeensummarizedinTable9.

960


Table9-FunctionalityMapforReferralRepositoryRole[ROL21]

CommCareHQ OpenMRS MARC-HISHRSHR23–RecordReferral X XSHR25–FulfillReferral X XSHR27–QueryReferrals * XAR01–AuditDisclosure X X XAR02-AuditRecord X X XX–Softwarepackagesupportsthenecessaryfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

BasedontheanalysisofCommCareHQ’scaseXMLdocumentation,itappearsthatthesoftwarepackagecouldsufficeasareferraldatarepository[ROL21].ThecaseXMLdocumentationandsamplesshowthecreationofareferral[SHR23]andfulfillment(viaaclose)[SHR25].Again,theexportAPIcanprovidefunctionalequivalencytothequeryoperation[SHR27]butnodocumentationaboutsupplyingqueryparameterscouldbefound.

OpenMRSdidnotappeartoprovideanendpointinterfaceforinvokingtheoperationsofrecord,updateorqueryreferraldata[SHR05,SHR07,SHR09];thereforesupportismarkedasnotsupported.

TheMARC-HISHRreferenceimplementationsupportsthenecessaryfunctionalitytorecord,updateand970queryreferraldata[SHR23,SHR25,SHR27]andauditsthedisclosureandcreationofdata[AR01,AR02].

Theanalysisfortherequiredfunctionalitytoimplementtheclinicalobservationrepositoryrole[ROL23]hasbeensummarizedinTable10.

Table10-FunctionalityMapforClinicalObservationRepositoryRole[ROL23]

CommCareHQ OpenMRS MARC-HISHRSHR01–RecordClinicalObservation * X XSHR03–QueryClinicalObservation * X XSHR13†-UpdateEncounter X X *AR01–AuditDisclosure X X XAR02–AuditRecord X X XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisofCommCareHQrevealedthatrecordingofobservations[SHR01]andlinkingtoencounters[SHR13]ispossiblethroughthe“update”caseXMLoperation.Itshouldbenotedthatonecaveatofusingthisoperationisthatwhileclinicalobservationsareatomicandaresubmittedaselementsofaparticularcase(viaupdatecase).AnotheroptionforutilizingCommCareHQintheSHRroleisviatheuseofxFormswithappropriateOpenRosametadatatocaptureobservationdata[SHR01].Bothofthese980


mechanismsmayrequireadditionalspecificationandcustomizationworktoensuretheyoperateinaninteroperablemanner.

OpenMRSsupportsthecreationandqueryingofclinicalobservations[SHR01,SHR03]andprovidesanopportunitytolinktheseobservationstoanencounter[SHR13].Furthermore,OpenMRSappearstoauditthecreationanddisclosureofthisdata[AR01,AR02].

TheMARC-HISHRsupportsthecreationandqueryofclinicalobservations[SHR01,SHR02]howeverprovidespartialsupportforlinkingthesetoanencounter(viaacarecompositionparadigm).

TheanalysisfortheclinicalencounterrepositoryissummarizedinTable11.

Table11-FunctionalityMapforClinicalEncounterRepositoryRole[ROL25]

CommCareHQ OpenMRS MARC-HISHRSHR11-CreateClinicalEncounter * X SHR13–UpdateClinicalEncounter X SHR15–QueryClinicalEncounter * X SHR25†–FulfillReferral X XAR01–AuditDisclosure X X XAR02–AuditRecord X X XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.990

Onceagain,analysisofCommCareHQfoundthatthe“update”methodofcaseXMLlooselymimicstheneededfunctionalityforsupportingthecreationofaclinicalencounter[SHR11]usingthevisitnumberparameter.ItisalsopossibletocreatexFormsthataresubmittedtoCommCareHQthatprovidestructureddatarelatedtotheencounter(encountersummaryrecord)[SHR11].BothofthesemechanismswouldrequirecustomizationsanddevelopmentofastandardsetofxFormsthattriggerthecreationand/orupdateofclinicalencounterstofunctionasanencounterrepository.

OpenMRSappearstoprovidethenecessaryfunctionalitytosupportthecreation,updateandquery[SHR11,SHR13,andSHR15]ofclinicalencounters.However,sincenopublicinterfacetoreferraldatacouldbeidentified,theabilityforanencountertofulfillareferralorencounterrequestcouldnotbedetermined.1000

TheMARC-HISHRsupportstheconceptofmanagingencounters,howeverthereareseveralmechanismsimplementedwithintheSHRtocreatetheseencounters.TheprimarymechanismofcreatingacarecompositionisnotsupportedintheMARC-HISHR7.

7MARC-HI,“MARC-HISharedHealthRecord,”http://wiki.marc-hi.ca/Demonstration_Servers/MARC-HI_Shared_Health_Record.


Thecareplanrepositoryservicerole[ROL27]analysisrevealedthatnoneofthecandidatesoftwarecouldsupporttheconceptofdiscretecareplans.OpenMRSsupportstheconceptofcreatinganencounter,butitcouldnotbedeterminedifsupportforcreatingfutureencountersissupported.TheresultsoftheanalysisareidentifiedinTable12.

Table12-CandidateFunctionMapforCarePlanRepositoryRole[ROL27]

CommCareHQ OpenMRS MARC-HISHRSHR17–RecordCarePlan SHR19-QueryCarePlans SHR11†–CreateClinicalEncounter ? ? AR01–AuditDisclosure ? X XAR02–AuditRecord X X XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

DocumentRepository1010Thedocumentrepositoryisresponsiblefortheregistration,queryandmaintenanceofclinicaldocumentswithinthesystem.Clinicaldocumentsareblobsofeitherbinaryorstructureddatathatrepresentpoint-in-timeobservations,summaries,referralsornotes.

Thedescriptionofthedocumentrepositoryinthissectiondescribesthefunctionalityofadocumentrepositoryratherthanthecommunicationsmechanismsforadocumentrepository.CommunicationsarecoveredinmoredepthinCommunicationsArchitectureonpage73.

RolesTherearetworolesidentifiedforthedocumentrepositoryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.1020

• DocumentRepositoryServiceProvider[ROL11]–Asystemimplementingadocumentrepositoryserviceprovidermustbecapableofstoringadocumentobjectanditsmeta-data,andmustbeabletoqueryandretrievethedocumentobjectusingthismeta-data.

• DocumentRepositoryServiceConsumer[ROL12]–Asystemimplementingadocumentrepositoryserviceconsumeriscapableofinvokingoperationsonafederateddocumentrepositoryserviceproviderforthepurposeofstoringandretrievingdocumentobjects.

IdentifiedOperationsThefollowingoperationshavebeenidentifiedforthedocumentrepository.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithDRwhichisusedtounambiguouslyidentifytheoperation.


StoreDocument[DR01]1030

Audit Repository Service Provider

[ROL15]

Document Repository Service Provider

[ROL11]

Audit Record [AR02]

Document Repository Service Consumer

[ROL12]

Store Document [DR01]

Acknowledgment [DR02]

Figure31–Storedocument[DR01]invocationpattern

Thestoredocumentoperation[DR01]registersthedocumentwiththerepository[ROL11]andwhichresultsinastoreofitscontents.Theresultofthisoperationisanacknowledgement[DR02]indicatingwhetherthestorageofthedocumentwassuccessful.

Thecreationofadocumentrecordintherepository[ROL11]mustresultinanaudit[AR02]ofrecordcreation.

QueryAvailableDocuments[DR03]


[ROL15]


[ROL11]



[ROL12]

Query Docs. [DR03]

List of Docs. [DR04]

Figure32-Queryavailabledocuments[DR03]invocationpattern1040

Thequeryavailabledocuments[DR03]operationallowstheconsumer[ROL12]tosolicitalistofavailabledocumentsfromtherepository[ROL11].Theresultofthissolicitationisalistofdocumentmeta-data[DR04]matchingthequeryoftheconsumer.

Therepositorycanusethislistofdocumentstosubsequentlyperformgetdocumentcontent[DR05]ondocumentsofinterest.Thisprocessiscompletedastwodistinctoperationsforperformanceandbandwidthreasons.


Aswithalldisclosureofdata,thequeryresultsinanaudit[AR01]ofdisclosureofinformation.

GetDocumentContent[DR05]


[ROL15]


[ROL11]



[ROL12]

Get Document [DR05]

Document Content [DR06]

Figure33-Getdocumentcontent[DR05]invocationpattern1050

Thegetdocumentcontent[DR05]operationisusedtofetchthecontentsofadocumentobjectfromtherepository[ROL11].Theconsumermustknowtheuniqueidentifierofthedocumentobjecttoperformthegetoperation.Theresultofthisoperationisamessagecontainingthedocumentcontent[DR06].

Theresultofdisclosingdocumentcontentresultsinanauditofdisclosure[AR01].

CandidateSoftwareThefollowingcandidatesoftwarepackageswereidentifiedforuseasadocumentrepositorywithinthehealthsystemspecified:

• OpenXDS(https://www.projects.openhealthtools.org/sf/go/page1046)• MicrosoftXDS.bSolution(http://ihe.codeplex.com/)• NISTPublicRepository(http://sourceforge.net/projects/iheos/)1060• MARC-HISHR(http://wiki.marc-hi.ca/Demonstration_Servers/MARC-HI_Shared_Health_Record)

Manycommercialclinicaldocumentmanagementsystemsexistbutwerenotincludedinthisanalysisasitfocusesonopensourcesolutions.

Candidate/FunctionMapThecandidatesoftwarepackageswerecomparedagainsttheoperationsidentifiedforthedocumentregistryandtheresultsofthisanalysishasbeensummarizedinTable13.


Table13-Documentrepositoryfunctionalitymap1070

OpenXDS Microsoft NIST MARC-HISHRDR01–StoreDocument X X X *DR03–QueryAvailableDocuments X X X *DR05–GetDocumentContent X X X *AR01†–AuditDisclosure X X X XAR02†–AuditRecord X X x XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisoftheXDSprojects(OpenXDS,MicrosoftXDS.bSolution,andNIST)showedthattheoperationsfromXDS.bregistryandXDS.brepositorymapdirectlytotherequiredoperationsforthedocumentrepositoryrole(ROL11):

• ITI-41(ProvideAndRegisterDocumentSet-b)mapsdirectlytoStoreDocument[DR01]• ITI-18(RegistryStoredQuery)mapstoQueryAvailableDocuments[DR03]• ITI-43(RetrieveDocument)mapsdirectlytoRetrieveDocument[DR05]• ITI-20(AuditTrailLoggingtoanAuditRecordRepository)mapstoAuditrequirements[AR01,

AR02]

ThereforeanXDSregistrythatsupportstheaforementionedprofilesiscapableofactingasan1080implementationofthedocumentrepositorywithinthesystem.

AnalysisofOpenXDS,MicrosoftXDS.bSolutionAcceleratorandtheNISTPublicRepositoryrevealthattheyareallsuitablecandidatesforthedocumentrepositoryhavingpassedatconnectathon.

TheMARC-HISHRisnotanXDSregistryandrepresentsareferenceimplementationofthepan-CanadiansharedhealthrecordusingHL7v3messaging.Thissoftwaresupportstheregistration,queryandfetch[DR01,DR03,DR05]ofdocumentshoweverdocumentsareclassifiedbasedontheircontent(i.e.:referrals,discharges,andgenericdocuments).Supportfordischargeandreferraldocumentsisfullyimplementedintheregistry,howeverthe“PatientClinicalDocumentRepository”ismarkedas0%supportedasofthetimeofthiswriting8.Thisisthereasonforthe“partial”supportmark.

CandidateSuitability1090Basedontheanalysisofthecandidatesoftware,thefollowingpackageshavebeenidentifiedasimplementingthenecessaryoperationstoactasadocumentrepositoryserviceprovider:

8MARC-HI,“SharedHealthRecordConformanceProfiles,”http://wiki.marc-hi.ca/Demonstration_Servers/MARC-HI_Shared_Health_Record#Conformance_Profile_Statements.


• OpenXDS–AsanXDS.brepositoryandregistrythatsupportsITI-41,ITI-43,ITI-18andITI-20,theOpenXDSsoftwarepackagesupportsthenecessaryfunctionalitytooperateasadocumentrepositoryserviceprovider.

• MicrosoftXDS.bSolutionAccelerator–LikeOpenXDS,theMicrosoftXDS.bDocumentRegistryandRepositorysolutionacceleratorsupportsthenecessaryfunctionalitytoactasadocumentrepositoryserviceprovider.

• NISTPublicRegistry–TheNISTpublicregistrysupportsthenecessaryoperationstosupportthedocumentrepositoryserviceprovider.1100

Thefollowingpackagescanactasadocumentrepositoryserviceprovider(fromafunctionalstandpoint)butmayrequireadditionalsetupand/ormodifications:

• MARC-HISharedHealthRecord–TheMARC-HISharedHealthRecordprojecthassupportforthestorageofdischargeandreferraldocuments,howeverfullimplementationoftherequiredconformanceprofile“ClinicalDocumentRepository”iscurrentlynotimplemented.SincetheSHRimplementationsupportsreferralanddischarge,itcanbeassumedthatgenericdocumenthandlingcanbeimplemented.

AuditRepositoryTheauditrepository(AR)isresponsibleforthestorageofauditsgeneratedbyvariousserviceswithinthehealthenterprise.Thisrepositoryrepresentsafederatedauditplatformthatfacilitateshealth1110systemsmonitoringandreporting.

Auditssenttotheauditrepositoryareexpectedtobenearreal-timeinnatureandshouldcontainthefollowinginformation:

• Whowasinvolvedintheclinicalact?(Clients,Providers,Observers,etc…)• Whendidtheactoccur?• Wheredidtheactoccur?• Whatinformationwasaffected?(Patientrecords,reports,observations,etc…)• Howwastheinformationaffected?(Disclosed,Created,Updated,etc…)

Thissectionoutlinesthefunctionalityofanauditrepositoryratherthanthedataand/orcommunicationofthisdata(whichisdiscussedinmoredetailinCommunicationsArchitectureonpage73)1120

TheauditrepositoryfunctionalityspecifiedinthissectionmerelyidentifiestheoperationsrequiredforanARtocollectauditinformation.Disclosureandreportingofauditinformationisnotafunctionofinteroperabilityandisoutofscopeforthisspecification.

RolesTherearetworolesidentifiedfortheauditrepositoryservice,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.


• AuditRepositoryServiceProvider[ROL15]–AsystemimplementingtheauditrepositoryserviceprovidemustbecapableofacceptingauditsforthecreationanddisclosureofPHI.

• AuditRepositoryServiceConsumer[ROL16]–Asystemimplementingtheauditrepository1130serviceconsumeriscapableofsendingauditstoafederatedauditrepository.

IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheauditrepository.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithARwhichisusedtounambiguouslyidentifytheoperation.

AuditDisclosure[AR01]


[ROL15]

Audit Repository Service Consumer

[ROL16]Audit Disclosure [AR01]

Figure34-Auditdisclosure[AR01]invocationpattern

Theauditdisclosureoperation[AR01]isanasynchronouscallfromtheauditrepositoryserviceconsumer[ROL16]totherepositoryprovider[ROL15]whichseekstorecordauditinformationrelatedtothedisclosureofinformation.1140

AuditRecordCreation/Update[AR02]


[ROL15]

Audit Repository Service Consumer

[ROL16]Audit Record [AR02]

Figure35-Auditrecordcreation/update[AR02]invocationpattern

Theauditrecordcreation/updateoperation[AR02]isanasynchronouscallfromtheauditrepositoryconsumer[ROL16]totherepository[ROL15]whichseekstorecordauditinformationrelatedtothemodificationofapatient’shealthprofileintheHIX.

AuditSecurityEvent[AR03]


[ROL15]

Federated Security Service Provider

[ROL17]Audit Security Evt. [AR03]

Figure36-Auditsecurityevent[AR03]invocationpattern


Theauditsecurityevent[AR03]operationisusedfortheauditofsecurityeventsoriginatingfromthe1150federatedsecurityservice[ROL17].Examplesofsecurityauditsincludepolicyfail,authenticationfail/success,tokenvalidationrequests,etc…

CandidateSoftwareThefollowingsoftwarepackageswereidentifiedascandidatepackagesfortheauditrepository[ROL15]role:

• OpenATNA(https://www.projects.openhealthtools.org/sf/projects/openatna/)

Inadditiontotheidentifiedsoftware,thefollowingoptionsarealsoviablefortheroleofauditrepository:

• HIPAATUniversalAuditRepository(http://www.hipaat.com/uar.php)• SolarwindsKiwiSyslogServer1160

Sinceauditingisanasynchronousoperationthatisintendedprimarilyforreportingandtracking,genericsoftwaresuchassyslogserverswhicharecapableofpersistingauditsaresuitableforthisrole.Itisalsounderstoodthatanauditrepositoryimplementationmaynotdifferentiatebetweentheoperationofrecordinganauditforcreate/updatevs.disclosurehowevertheyMUSTdifferentiatebetweentheevents(i.e.:oneoperationforsubmittingauditsissuitable,howeverthatoperationmustbeabletodifferentiatebetweendisclosureeventsandcreate/updateevents).

HealthInformationeXchangeTheHealthInformationeXchange(HIX)isresponsibleforprovidingasingle,coherentsetofinterfacesthroughwhichconsumerapplicationscancommunicatewithregistries.ItisthejoboftheHIXto:

• Normalize–TheHIX’sprimaryroleisthatofanormalization/transformationengine.1170Normalizationinvolvestheprocessof“transforming”databetweenthevariousclinicalrepositories.NormalizationofstructuresandterminologiesisimportantfromaninteroperabilitystandpointinthattheyfacilitatethereuseofotherserviceswithintheHIX(i.e.:Allorchestration,validation,andauthenticationroutinesarewrittenagainstthenormalizedform,sotheycanbeusednomattertheinputstructure).

• Validation/Authentication–SincetheHIXpresentsasinglepointofcontactforclinicalrepositories,itisalsopossiblefortheHIXtovalidatedataandauthenticationtokensinafederatedmanner.

• SecondaryUseReporting–SinceallmessagesexchangedinajurisdictionwouldflowthroughtheHIX,itispossibletoperformsecondaryusereportingandbusinessintelligence1180againstthedatacontainedwithinthemessagesflowingthroughtheHIX.

• Orchestration–TheHIXisalsoresponsiblefororchestratingclinicalrepositoriesandregistriesinamannerthatadherestothepolicyguidelinesofthelocaljurisdiction.ByhavinganHIXactasa“gatekeeper”priortodatastorageandretrieval,thejurisdictioncanestablishandenforceprocessesonallclinicaltransactions.


• Durability–DurabilitydescribesthenotionthattheHIXguaranteesdeliveryofanycommunicationregardlessofpoweroutage,and/orservicedisruptionoftheclinicalrepository.

• BatchProcessing–Eachoftheclinicalrepositoriesidentifiedexpectdiscretepiecesofclinicaldata.However,becauseofbandwidthlimitations,andevenlackofconnectivityin1190someareasisaconcern,theHIXshouldallowrequeststobebatched.Batchesaredisaggregatedandrepresentedasindividual“puts”againstclinicalregistries/repositories.

ConsiderascenariowhereHospitalInformationSystem(HIS)AusesICD-9-CMcodeV22.2torecordadiagnosisofpregnancyforapatient.Whenthesamepatientpresentsatadifferenthospital,andtheHISaccessestheObservationRepository[ROL23]searchingforICD-10-CMcodeZ33.1(pregnancystate,incidental),therepository[ROL23]wouldnotreturnanyresults.IfHISAandHISBbothuseanHIXmessagingserviceprovider[ROL13]tointegratewiththeobservationrepository[ROL23],thentheHIXwould“normalize”theICD-9-CMcodeV22.2toacanonicalcode(forexampleSNOMED-CT)whentheconditionwasrecorded.WhenHISBqueriesforZ33.1,theHIXwould1200normalizetheICD-10-CMcodetothesamecanonicalcodepriortoqueryingtherepository.

TheHIXisnotintendedtobecometheprimarydatastoreofconsumerapplications;ratheritisafacilitatorofsharinginformation.OnlydatawhichisdeemedsuitabletobesharedshouldbesenttotheHIX.

Forexample,ifaprojectisinitiatedwhichmonitorsaclientadherencetoamedicationregiment;eachdatapiecemaynotbesuitableforsharing.Ratheranaggregatesummary(weeklyormonthly)wouldbeamoresuitablecandidateforsharingofdata.

TrustedNetworkTheHIXisexpectedtooperateontheprincipalofatrustednetwork.Thismeansthatallrepositories,registries,HIXservicesandcertifiedconsumersaremembersofatrustednetworkandareissuedkeys1210whicharerequiredtoparticipateinthetrust.

Figure37illustratestheconceptofthetrustednetwork.ConsumerapplicationsthatarecertifiedforusewiththeHIXareissuedaclientcertificate.Byhavingacertificate,aconsumerapplicationhasassertedthatitcomplieswithregionalpoliciesregardinghealthinformation(auditing,authentication,etc…).AnyapplicationsthatdonotpossessacertificatearenotpermittedtoconnecttotheHIX,oranyotherserviceswithinthetrustednetwork.

Insideofthetrustednetwork,“behindtheHIX”servicesareseparatedfrom“consumer”rolesandtheHIXactsasagatewayfortheseservices.Thisseparationcanbelogical(i.e.:usingdifferentkeys)orphysical(i.e.:segregatednetworkinterfaces)


Trusted Network

HIX

SHR[ROL09]

PR[ROL03]

CR[ROL01]

Certified Consumer Application

Certified Consumer Application

Uncertified Consumer Application

Consumers Behind theHIX

1220

Figure37-Trustednetwork

SeveralmechanismsexistforcreatingatrustednetworksuchasTNC9,ordualauthenticationusingcertificates.

RolesTherearefourrolesidentifiedfortheHIX,eachroleisuniquelyidentifiedbyanidentifierstartingwithROL.Thisidentificationisdonetounambiguouslyidentifytheroleswithinthisdocument.

• HIXMessagingServiceProvider[ROL13]–AsystemimplementingtheroleofHIXmessagingserviceprovidermustbecapableoftranslating/mappingmessagestructures,ensuringmessagesareroutedtoappropriaterepositoriesandregistriesinadurablemanner.

• HIXMessagingServiceConsumer[ROL14]–TheroleofanHIXmessagingserviceconsumeris1230intendedtobecombinedwithotherconsumerroles(forexample:ClientRegistryServiceConsumer[ROL02])onlytheconsumerrole[ROL14]mustbeabletoinvokeservicesviatheHIX.

• HIXOrchestrationServiceProvider[ROL27]–AsystemimplementingtheroleofanHIXorchestrationserviceprovidermustbecapableoforchestrating,orautomating,businessprocessesacrossclinicalrepositories.

9TrustedComputingGroup,“TrustedNetworkConnect,”http://www.trustedcomputinggroup.org/developers/trusted_network_connect.


DesignPatternsThereareseveralwaysthatanHIXcanbedesigned,andthechoiceofdeploymentwillaffectthemannerinwhichseveraloftheoperationsoftheHIXfunction.Todescribethedifferentpatternsforintegratingsoftware,aclinicalexampleofrecordingaclinicalobservation[SHR01]intheobservationrepository[ROL23]viatheHIXmessagingprovider[ROL13].1240

Broker/HubandSpokePatternThebrokerorhubandspokepatternisanimplementationstylewherebyallmessagesfromconsumersaresenttoasinglefarmofdedicatedservicesthatbrokercommunicationswiththeclinicalregistries.Inthispattern,theHIXisactingasamessagingprovider[ROL13]andorchestrationprovider[ROL27].

Becausethebrokermusthandlethevalidationandresolutionofdatafromanynumberofdifferentsourcesanddatastructures,acanonicalformisoftheutmostimportance.Forexample,ifaHIXexchangesmessagesfromOpenMRSinstancesandHL7v2systems,thenacanonicalformrepresentingtheintersectofdataelementsfromthesetwomessagingformatsmustbeimplementedinthebrokertoreducecomplexityinimplementinglogicintheHIX.

Thereareseveraladvantagestothispattern,namelythatthereisminimallatencyintroducedinthe1250processingofamessage,thesystemiseasiertounderstandandallbusinesslogiciscontainedinoneservice.Additionally,thepatterniswellsuitedwhendeployingservicesthatarenot“enterprise”awareastheHIXprovidesallresolution(whattheservicethinksarelocalidentifiers).

Thispatternisnotwithoutproblemshowever,astheHIXbecomesresponsibleforunderstandingthebusinesslogicandvalidationconstraintsofallclinicaldomainsbeingintegrated.Thebrokermustalsobeupdatedandmaintainedwhenevernewclinicalrepositoriesorregistriesareaddedtothesystemwhichintroducescomplexityandmaintenanceissues.

Inthecasewhereenterpriseawareservicesaredeployed,duplicationincallsforresolution,validationandtranslationofcodes,providersandclientsmaybeduplicatedaswell.Additionally,onemustcarefullychoosewhichactionsrequireresolutionandverificationasdisclosurefromeachoftheHIX1260serviceroleswillmostlikelyresultinadisclosureaudit.

Inthecontextoftheexample,theinvocationpatternwouldbesimilartothatillustratedinFigure38.


HIX Provider[ROL13 & ROL27]

HIX & OBS Consumer

[ROL14 & ROL24]

Record Obs [SHR01]


[ROL01]

Resolve Identifiers [CR01]

Provider Registry Service Provider

[ROL03]

Resolve Identifiers [PR01]


Provider[ROL23]

Record Obs [SHR01]

Acknowledgement [SHR02]Acknowledgement [SHR02]

Figure38-Brokerpatternexample

ServiceBusPatternTheservicebuspatternisdifferentinthattheHIXmessagingprovider[ROL13]actsonlyasaconduitthroughwhichservicescaninvokeoperationsonclinicalrepositoriesandregistries.Aswiththebrokerpattern,alltrafficflowsthroughthemessagingprovider[ROL13]whichisresponsiblefornormalizationofmessagestructures,terminology,anddurabledeliveryofmessages.1270

Ratherthanthebrokerorchestratingthevalidationandresolutionofclientidentifiers,eachclinicalrepositoryorservicewithinthebusisresponsibleforperformingitsownvalidationusingservicesprovidedbythebus[ROL13].

Themajoradvantagetotheservicebuspatternistheloosecouplingofconsumersfromproviders.SincetheHIXisonlyprovidingaconduit,newserviceproviderscanbeprovidedviatheHIXwithnochangetheHIXitself.Existingserviceproviderscanbemovedand“swappedout”withouthavingtoreconfiguretheconsumers.Additionally,thispatternleavesvalidationofdatatoeachconsumerwhichallowsformorespecializedresolution/validationrules.

Thispatterndoesintroducelatency(astheHIXoperatesonapublish/subscribemodel)andincreasesthecomplexityofunderstandinghowmessagesareorchestratedintheHIX(whichisabus).Additionally,1280theburdenofleveragingHIXservicesisplacedontheclinicalrepositories,whichmeansthattheyshouldbe“serviceaware”.

Inthecontextoftheexample,theinvocationpatternwouldbesimilartothatillustratedinFigure39.


HIX & OBS Consumer

[ROL14 & ROL24]

Record Obs [SHR01]


[ROL01]


[ROL03]


Resolve Identifiers [CR01] via HIX

Resolve Identifiers [PR01] via HIX

HIX Messaging Service Provider

[ROL13]


Provider[ROL23]

Record Obs [SHR01]


Figure39-Servicebuspatternexample

HybridServiceBus/OrchestratorPatternItispossibletohybridizethebrokerandbuspatterns.Inthispattern,theroleofHIXmessagingprovider[ROL13]andHIXorchestrationprovider[ROL27]areseparated.Theorchestrationprovider[ROL27]isinvokedtoperform“bootstrapping”ofthemessagepriortopublishingtothedestinationregistry.1290

Theorchestratorwillexecutecommonworkflowsandinvokeservicesforresolution,validationandterminologymappingviatheHIX(thebuspattern).Likethebrokerpattern,thedevelopmentanduseofacanonicaldataformatisimportanttoreducecomplexityofimplementingorchestrationsontheHIXorchestrationprovider[ROL27].

Advantagestothispatternareloosecouplingofclinicalregistriesfromtheeachother,andcentralizedvalidationcriteria.Thispatterndoesnotpreventregistriesfromperformingtheirowndataprocesses,andprovidescommondataprocessingforregistriesthataren’tservicesaware(i.e.:notcapableofconsumingservices).

Thispatternissubjecttothesamedisadvantagesasthefullservicebuspatternintermsofmessagelatencyandcomplexity.Additionally,theorchestrationprovider[ROL27]mustcarefullybesetupasto1300onlyvalidate/resolvemessagesthatarereceivedfromsourcesthathavenotalreadybeenvalidatedorresolved.

Inthecontextoftheexample,theinvocationpatternwouldappearasillustratedinFigure40.


HIX & OBS Consumer

[ROL14 & ROL24]

Record Obs [SHR01]


[ROL01]


[ROL03]



Provider[ROL23]

Record Obs [SHR01]


HIX Orchestration Provider[ROL27]

Invoke Workflow [HIX09]

Resolve Identifiers [CR01] via HIX

Resolve Identifiers [PR01] via HIX

HIX Messaging Provider[ROL13]

Figure40-HybridBus/BrokerPatternExample

IdentifiedOperationsTheidentifiedoperationsfortheHIXaren’tnecessarilyoperationsperse,rathertheyarerequired“operations”thatanHIXshouldfulfill,communicationsbetweentheHIXandrepositoriesisoutlinedintheCommunicationsArchitectureonpage73.

AlloperationsfortheHIXareassignedauniqueidentifierprefixedwithHIX.Thisidentificationisdoneto1310unambiguouslyidentifytheoperationthroughoutthedocument.

SubmitMessage[HIX01]


[ROL13]

HIX Messaging Service Consumer

[ROL14]

Submit Msg [HIX01]

Msg. Result [HIX02]

Clinical Repository / Registry[ROLXX]

Invoke

Response


Invoke Orch. [HIX09]

Figure41-SubmitHIXmessage[HIX01]invocationpattern


TheprocessofsubmittingamessagetotheHIX[HIX01]isasecuredoperationbetweentheHIXmessagingserviceprovider[ROL13]andaconsumercapableofcontactingtheHIX[ROL14].TheHIXoptionallyinvokesanorchestration[HIX07]toresolveidentifiersandnormalizethedataprovidedbytheconsumer[ROL14].Themessagingprovidershouldinvokethetargetrepository[XX].

ThesequenceforthisoperationisillustratedinFigure42.Notethatfromasoftwarearchitecturepointofview,thesequencediagramismerelyconcernedwiththeorderofinvocationratherthanthe1320messagingorcommunicationsmechanismsbetweeneachoftheroles.

HIX Messaging : ROL13HIX Consumer : ROL14

Submit Msg: HIX01()

Target RepositoryHIX Orch. Provider : ROL27

Invoke Orch: HIX09()

Resolve: HIX10()

Normalize Message: HIX07()

Resolved Message

In a pure service bus model, this is performed by the repository and not the HIX system (i.e.: the registry becomes ROL27 and the sequence is reveresed)

Invoke

Response

De-normalize message: HIX07()

Response

Figure42-Sequenceofsubmitmessage[HIX01]


Theresultantmessagefromtheclinicalrepositorywillbede-normalizedbackintoanappropriateformfortheconsumer[HIX02].Forexample,ifaconsumerrequestsinformationinCDAtherequestisnormalizedintowhateverformattherepository(ies)requireandtheresultfromtheserepositoriesarethentransformedbackintoCDA.

SubmitBatch[HIX03]

Figure43-Submitbatch[HIX03]invocationpattern1330

Thesubmitbatchoperation[HIX03]allowsHIXmessagingconsumers[ROL14]tosubmitabatchofclinicaldatatotheHIXmessagingprovider[ROL13].Thisdataisdisaggregatedandtheclinicalrepositoriesarepopulatedwithdiscreteclinicaldataelements,additionallytheentirebatchmessageissubmittedtotheclinicaldocumentrepository[ROL11]sothatthereport(orbatch)issavedasasnapshot.

Abatchcanbeeitherasummarydocument(forexample,aCCDasinHITSPC32)orasubmissionofdiscretemessagesinonerequest.TheoptionsforsubmittingbatchesaredescribedinmoredetailinCommunicationsArchitectureonpage73.

ThesequenceforthesubmissionofabatchmessageisillustratedinFigure44.Thisfigureonlyillustratesthesequenceofinvokingtheoperationsoneachservicerole;itdoesnotspecifythecommunications1340formatbetweeneachcomponent,thisinformationcanbefoundinCommunicationsArchitectureonpage73.



Submit Batch: HIX03()

Repo 1HIX Orch. : ROL27


Resolve: HIX10()

Normalize Structure: HIX07()

Acknowledge

Order of this invocation does not matter,

as long as the previous operation is successful

the next can continue

Put Discrete Data

Acknowledge

Repo 2

Put Discrete Data

Acknowledgement

Acknowledgement

Aggregate Acks: ()

Doc. Repo

Register Document: DR01()

Acknowledgement: DR02

Figure44-Sequenceforsubmittingbatchdata[HIX03]

Ifadocumentisusedforbatchsubmission,thennormalizationshouldoccuronthewrapper(i.e.:routinginformation)ratherthanthedocumentpayload.Structureddocumentsshouldbeusedforsubmissionofbatchesastheypermitdisaggregationofdata.


ItisrecommendedthattheHIXorchestrationprovider[ROL27]beusedtoorchestratethedisaggregationofthebatchandcoordinationofcalls.Additionally,compensationlogicshouldbeincludedintheHIXorchestrationprovider[ROL27]tocleananyremnantsofpartialdata.1350

AggregateClinicalSummary[HIX05]

HIX Messaging Service Consumer

[ROL14]

Get Summary [HIX05]

Aggregate Results [HIX06]



Clinical Repository / Registry 2[ROL09]



Get Summary [SHR21]

Get Summary[SHR21]

Get Summary[SHR21]


[ROL13]PHI List[SHR22]

PHI List[SHR22]

PHI List[SHR22]

Figure45-Aggregateclinicalsummary[HIX05]invocationpattern

Theaggregateclinicalsummary[HIX05]issimilartoareversebatch.Inthisoperation,aHIXmessagingconsumerrequests“allinformation”relatedtoaclientfromtheHIX[ROL13].TheHIXorchestrates[ROL27]theretrievalofdatafromclinicalrepositoriesandaggregatesthemintoasingleresponse[HIX06]fortheconsumer[ROL14].

ItisrecommendedthattheclinicalrepositoriesthatparticipateintheaggregationoperationimplementtheSHRrole[ROL09]asthiswouldreducethenumberofqueriestheHIXorchestration[ROL27]needstoexecute.ItispossibletoperformaggregationwithservicesthatdonotimplementSHR[ROL09]1360howeverdiscretequerieswouldneedtobeexecutedtosupportthisfunctionality.

ThesequenceofinvocationisoutlinedinFigure46.Notethatthissequencediagrammerelyshowstheorderofinvocationanddoesnotassumeanyparticulartypeofmessagingformat,formoreinformationrelatedtothecommunicationofsystemsimplementingrolesseeCommunicationsArchitectureonpage73.



Aggregate Clinical Summary: HIX05()

Repo 1 : ROL09HIX Orch. : ROL27


Resolve: HIX10()

Normalize Structure: HIX07()

Aggregated PHI

Get Summary: SHR21()

Aggregated PHI: HIX06

Repo 2 : ROL09

Get Summary: SHR21()

PHI List: SHR22

PHI List: SHR22

Aggregate PHI: ()

De-Normalize Structures: HIX07()

Figure46-Aggregateclinicalsummary[HIX05]sequence


TransformDataStructures[HIX07]


[ROL13]


[ROL13]

Transform Data [HIX07]


Translate Code [TR05]

Transformed Data [HIX08]

Figure47-Transformdatastructure[HIX07]invocationpattern1370

Thetransformdatastructuresoperation[HIX07]isaninternalfunctionoftheHIXthatallowsforthetransformationofadatastructurefromoneformatintoacanonicalform,andfromanormalizedformbackintoanendpointform.Theresultofthetransformoperation[HIX07]isanewstructure[HIX08]thathassemanticequivalencytotheoriginalstructure.

Transformationofdatastructuresmayalsocontacttheterminologyservices[ROL07]providertoperformtranslationofcodes[TR05]toandfromnormalizedforms.

InvokeOrchestration[HIX09]


[ROL13]



Invoke Result [HIX10]

Submit Message [HIX01]

Figure48-Invokeorchestration[HIX09]invocationpattern

Theinvokeorchestrationoperation[HIX09]isaninternaloperationwherebyamessagingservice1380provider[ROL13]invokesanorchestrationontheorchestrationprovider[ROL27]toperformabusinessprocess.Theresultofthisinvocation[HIX10]ispublishedbacktotheHIXmessagingserviceprovider[ROL13].

Duringthecourseofexecution,theHIXorchestrationprovidermayrequiretheexecutionofanoperationwithinthehealthsystem.SuchrequestsarepublishedtotheHIXasasubmitmessage[HIX01]operation.ThereasonforthisexecutionpatternisserviceswithinthesystemarecontrolledalwayscontrolledbytheHIX,andnopoint-to-pointcommunicationsexist.


ResumeOrchestration[HIX11]Theresumeorchestrationoperation[HIX11]speakstothedurabilityoftheHIX.WhenaconsumerapplicationsubmitsamessagetotheHIX,itmustbeguaranteedthatthemessagewillbeexecutedno1390matterwhatconditionsarise(i.e.:AvalidinvocationontheHIXwillalwaysresultinfullexecution).WhenanissueoccurswithintheHIXsuchasapowerloss,serviceoutage,ordisastertheHIXwill“suspend”anorchestrationprocess.Oncesuspendedanorchestrationcanberesumedaftertriggersaremet(i.e.:afterfiveminutes,afteruserintervention,powerrestoration,etc…).

WhentheHIXorchestrationisresumed,executionwillbeginatthelastsuccessfulcheckpoint.

CandidateSoftwareAsstatedintheDesignPatternssectiononpage55,thereareseveraldifferentmannersinwhichanHIXcanbedesigned.ThedesignchoiceswillaffectthedecisionofwhichHIXsoftwarepackage(orcombinationofpackages)isusedtoimplementtheHIX.

Whenusingabrokerpattern,specializedsoftwarepackageswithclinicalknowledgeinalldomainssuch1400asez-HIS(http://ricardoquintano.wix.com/ezvida#!soluções-ez-health/vstc5=ez-ehr)maybepreferredastheHIXisresponsibleforperformingandorchestratinginteractions.

Whenusingabusorhybridapproach,moregeneralizedsoftwaresuchasMuleESB(http://www.mulesoft.com/mule-esb-open-source-esb)orMicrosoftBizTalk(http://microsoft.com/biztalk)servermaybepreferredastheyfacilitatesystem-systemcommunicationsinagenericway.

Becausethereareavastnumberofintegrationplatforms,theanalysisforsoftwarepackagesfortheHIXwasconstrainedtothefollowingsolutions:

• MulesoftESBCommunityEd.(http://www.mulesoft.com/mule-esb-open-source-esb)• MirthConnect(http://www.mirthcorp.com/products/mirth-connect)1410• OpenESB(http://wiki.open-esb.java.net/)• Nuntium(http://instedd.org/technologies/nuntium/)

Thefollowingadditionalintegrationtechnologieswereidentifiedhoweverarenotincludedinthisanalysisastheyarecommercialinnature.

• MicrosoftBizTalkServer(http://microsoft.com/biztalk)• DellBoomi(http://www.boomi.com/)• IntelSOAExpresswayForHealthcare

(http://www.intel.com/about/companyinfo/healthcare/products/soa/)• IBMWebsphere(http://www-01.ibm.com/software/websphere/)• OracleWebLogic(formerlyBEAWebLogic)1420

(http://www.oracle.com/technetwork/middleware/weblogic/)


Analysisofez-HISwasnotpossibleasnoEnglishlanguagedocumentationcouldbefoundregardingthefeaturesofez-HIS.

Candidate/FunctionMap Mule Mirth OpenESBHIX01–SubmitMessage X X XHIX03–SubmitBatch/Disaggregate * *HIX05–AggregateClinicalSummary * *HIX07–TransformDataStructures * X *HIX09–InvokeOrchestration X XHIX11–ResumeOrchestration ? XSEC03†–ValidateToken ? XX–Softwarepackagesupportsthenecessaryfunctionality†-Thesoftwarepackageisabletoinvokethisfunctionality*-Onlypartialfunctionalitycouldbeidentified?–Functionalityisnotidentifiedindocumentationandcouldnotbefoundinreferencedeployments.

AnalysisforMuleESBwasperformedonthecommunityversionofMule’sproduct10asitmeetstheopensourceconstraintofthisproject.Theproducthassupportfororchestratingcalls[HIX09]androutinginvocationstoclinicalrepositoriesandregistriesviatheESB[HIX01].Transformingdatato/fromanormalizedform[HIX07]isperformedviaXSLTandXQLtransforms,whichmeansthatjurisdictionswillneedtowritethesepriortousingMule(orfindexistingtransforms).Thesubmitbatchandaggregation1430operationsoftheHIX[HIX03,HIX05]canbeimplementedviatheorchestrationsupport,andismarkedaspartialascustomizationtotheproductisneededpriortothisfunctionalitybeingavailable.

MuleESBissuitableasagenericsolutionasbothanHIXmessagereceiver[ROL13]andanorchestrator[ROL27]andissuitedforuseinanyofthethreepatternsidentifiedinthisspecification.SinceMuleESBisagenericproduct,customizationwillneedtobeperformedtofacilitatemapping,andorchestratingofclinicalservices.

MirthConnectappearstoactasatransformationenginewherebymessagesreceivedonsourcechannelscanberoutedtoadestination[HIX01]andtransformed[HIX07].Theproductappearstobeabrokerformessagecommunications[ROL13]ratherthanaservicebustechnology(itappearstolackpub/subcapabilities)andaccesstotheunderlyingESBtechnologyisnotpossible11.Thismaymake1440maintenancemoredifficultastheHIXevolvesandincludesmoreendpoints.

AlthoughtransformstoanormalizedformcanoccurwithinMirth,itappearsthatMirthhasnosupportfororchestration[HIX09]directly.Thisfunctionalitycanbemimickedbynormalizingandsendingto

10MuleSoft,“MuleESB,”http://www.mulesoft.com/downloads/mule-esb.pdf.11Mirth,“MirthConnectRoadmap,”http://www.mirthcorp.com/community/wiki/display/mirth/Mirth+Connect+Roadmap.


anothersourcechannel,orsendingnormalizeddatatoanadditionalsystemwhichperformsorchestrations[ROL27].

ThemajoradvantagetousingMirthistheplethoraofavailabletransformsto/fromhealthstandardssuchasHL7v2,v3andIXS.Thisprovidesarunningstartforthetransformationofmessages[HIX07].Mirthissuitableasamessagingserviceprovider[ROL13]howeverwouldneedtobepairedwithanorchestrationprovider[ROL27]toprovidenecessaryfunctionalitytoactasanentireHIX.

OpenESB(anditspartnerprojectGlassfishESB)isagenericservicebustechnologythatfacilitatesthe1450routing[HIX01]andorchestrating[HIX09]ofmessagesbetweenclinicalrepositoriesandregistries.OpenESBsupportsdurableorchestration[HIX11]viaitsBPELinstancemonitoring

OpenESBsupportstransformationofmessages[HIX07],howeversinceitisagenericintegrationenginejurisdictionswouldneedtoimplementthesetransformsusingXSLT(oracquirethem).Additionally,theorchestrationofservicestoaggregateclinicaldata[HIX05]andthedisaggregationofbatchdata[HIX03]wouldrequireimplementationefforttosupport.

LikeMuleESB,OpenESBiswellsuitedtoactastheHIXmessagingprovider[ROL13]andtheorchestrationprovider[ROL27]andcanbeusedinanyofthepatternsidentifiedforintegration.CustomizationanddevelopmentofintegrationswithOpenESBwouldberequiredbeforeafullyfunctionalHIXcouldberealized.1460

ConsumerApplicationsConsumerapplicationsareaclassificationofapplicationsthatconsumeserviceproviderfunctionalitythroughtheHIX.ConsumerapplicationsarevariedandcanbeanEMRsoftwarepackagesuchasadeploymentofOpenMRS,oragatewayfordumbphonessuchasNuntiumorRapidSMS.

Becausethenumberoftypesanddeploymentsofconsumerapplicationsispotentiallyhuge(everyterminalateveryhospital,ruralclinic,SMSandIVRgateways,etc...)theroleofstandardsplaysaveryimportantpartofcommunicatingwiththeHIX.

ConsumerApplicationRolesConsumerswillimplementoneormoreconsumerrolesidentifiedinthisspecification.Thetypesofrolesthatconsumersimplementwilldependsolelyonthefunctionalitytheyprovidetotheirendusers.1470

Forexample,adeploymentofRapidSMSthatactsasadiabetesprogrammemaywishtoprovideobservationstotheHIXandretrieveclinicalsummariesfromtheHIX.TheRapidSMSdeploymentwouldactasanObservationRepositoryServiceConsumer[ROL24],andaHIXMessagingConsumer[ROL14]andwouldneedtobeabletoinvokethenecessaryoperations[SHR01,HIX01,HIX05]andinterprettheresponsesofthoseoperations[SHR02,HIX02,HIX06].

Althoughthisspecificationisnotprescriptiveofthecombinationsofrolesthatanyoneconsumerapplicationshouldimplement,itisexpectedthatallconsumerapplicationswillatminimumsupportthefollowingroles:


• HIXMessagingServiceConsumer[ROL14]–SinceconsumerapplicationswillcommunicatewiththeHIX,itisexpectedthattheywillbecapableofimplementingasubsetoftheHIXconsumer1480[ROL14]role.SpecificallysubmissionofmessagestotheHIX[HIX01,HIX02].

• FederatedSecurityServiceConsumer[ROL18]–SinceconsumingapplicationsarenotincludedintheHIX’strustednetwork,theywillbeexpectedtocontactthefederatedsecurityservice[ROL17]foranauthenticationtoken[SEC01]whenaccessingservicesintheHIX.

Thisspecificationdoesnotimposebehaviorsoroperationsthatshouldbefoundwithintheconsumerapplications.Additionally,howtheconsumerapplicationcollectsinformationfromtheedgedevice(IVR,SMS,Forms,HTML,etc…)isnotinscopeforthisspecification.AslongastheminimumdataelementsforeachoperationarefilledtheconsumerapplicationcanparticipateintheHIX.

Asanexample,considerascenariowhereCommCareisusedtoperformreferralsandkeeptrackofencountersandobservationsforamaternalhealthprojectwithinajurisdiction.Thesamejurisdiction1490usesChildCount+torecordobservationsrelatedtopregnantwomenwithHIV.

InthisscenariotheinstanceofCommCarewouldcontinuetocollectinformationusingOpenRosaandxFormsfromsmartphonesitsprovidersuse,andChildCount+wouldcontinuetocollectinformationusingSMSmessages.Themajorityoftheseapplications’architecturewouldremainunchanged,exceptforthe“sharing”ofdatawiththeHIX:

• WhenanewclientisaddedtoCommCareorCC+,thesystemswould“reachout”totheHIXtodetermineifajurisdictionalclientrecordalreadyexists[CR01],ifsotheclientrecordisupdatedwiththelocalidentifierintheCommCare/CC+system[CR08].AlternativelyiftheCommCare/CC+systemknowsthepatient’sjurisdictionalid(suchasNID)itcansimplyregisteraclientwiththelocalidentifierandNID[CR05]1500

• Whenanewobservation,encounterorreferralissubmittedtotheCommCareinstance,CommCarewillgenerateanappropriatemessage[HIX01]andsendittotheHIX.Alternatively,CommCaremayqueueindividualdataelementsandsubmitabatch[HIX03].ThesameprocessappliestoaCC+instancethatwishestocommunicatewiththeHIX.

AdeploymentofthissampleinfrastructuremayappearasillustratedinFigure49.NotethatneitherChildCount+norCommCarecurrentlysupporttheabilitytoraiseeventsorsharedatawiththeHIXandwouldrequiremodificationstoinvoketheappropriateinteractionswiththeHIX.


Trusted InfrastructureHIX Messaging Provider[ROL13]

Child Count Plus[ROL14, ROL18, ROL20, ROL02]

SHR05/SHR06

SMS

ProviderSecurity Services

[ROL17]

SEC03/SEC04

SEC01/SEC02

CommCare[ROL14, ROL18, ROL21, ROL26, ROL24, ROL02]

SHR23/SHR24SHR01/SHR02SHR11/SHR12

OpenRosa

Provider

Figure49-SampledeploymentusingCCPandCommCaretogatherdataandsubmittoHIX

IdentifiedConsumerApplications1510ThefollowingconsumerapplicationshavebeenidentifiedascandidatesforconsumingservicesfromtheHIXandserviceswithinthesystemdescribedinthisspecification:

• InSTEDDSuite(Remindem,Seentags,ReportingWheel)(http://instedd.org/technologies/)• InSTEDDNuntium12(http://instedd.org/technologies/nuntium/)• RapidSMS(http://www.rapidsms.org/)• ChildCount+(http://www.childcount.org/)• OpenMRS(http://openmrs.org)• ez-HIS/ez-EHR13(http://www.ezvida.com.br/)• CommCare/CommCareHQ(http://www.Dimagi.com/commcare/)

Asstatedbefore,thechoiceofwhichservicestoconsumefromtheHIXdependsonthedeployment/1520usescenarioforthefieldproject.Table14Illustratesaveryhighlevelanalysisoftheentitiesandfunctionsthatarepresentineachofthesesoftwarepackagesandmarkswhatconsumerrolesarepotentialcandidatesforimplementation.

Duetospacerequirementsonthepage,onlythecodesareused,referencefortheseoperationcodescanbefoundinRole&OperationReferenceonpage109.Notethatthesummaryandallanalysisnotesarebasedonthedocumentationpresentforthe“trunk”version(withoutmodifications)availableatthetimeofthiswriting,noroadmaporplannedfeatureswereincludedaspartoftheanalysis.

12Nuntiumisageneralpurposeintegrationengineandhasbeenseparatedfromotherprojectsforthisreason13Englishdocumentationcouldnotbelocatedsothisispurelyanassumption


Table14-ConsumerApplicationRolesAnalysis

InSTEDD Nuntium ChildCount+ OpenMRS CommCareROL02–CR * CR03,CR05,

CR08* *

ROL04–PR * PR05,PR08,PR03

* *

ROL06–FR * * * ROL08–Term. * * ROL10–SHR * * * ROL12–Docs * * DR01ROL14–HIX HIX01,

HIX05HIX01,HIX03,

HIX05HIX01,HIX03 HIX01,HIX03,

HIX05HIX01,HIX03,

HIX05ROL18–Security SEC01 SEC01 SEC01 SEC01 SEC01ROL20–Cond. SHR05 SHR05ROL22–Referral SHR23 SHR23,SHR25ROL24–Obs. SHR01 * SHR05,SHR07 * ROL26–Encounter * SHR11,SHR13 * SHR11,SHR13ROL28–CRNotif. CR07,CR10 ROL29–PRNotif. PR07,PR10 ROL31–CarePlan *-IndicatesthatalloperationsintheconsumerrolearecandidatesRowshighlightedinredareconsideredmandatoryforcommunicationwiththeHIX

SeveralapplicationswerechosenfromtheInSTEDDplatform(excludingNuntium12)toanalyzehowthey1530couldbeusedtosharedatawiththeHIX.

Remindemisageneralpurposeremindersystemthatcanschedulereminderstobesenttoacellphonebasedontimeconstraints.AlthoughRemindemcan’tbeusedtoaccesstheHIXdirectly,itcanbeleveragedbyothersystemsbelow(orabove)theHIXtoschedulereminders(i.e.:anotherconsumerorproviderwouldsubscribetoreminderlistsbasedoncertainconditions).Remindemitselfmaybeacandidateforreceivingclientandproviderregistrycreationandupdatenotificationstochangesubscriptiondata(i.e.:wheretosendreminders).

SeentagsisanotherInSTEDDproductthatcanbeleveragedbyotherconsumerapplications(especiallySMSgateways)tocorrectmistypedorincorrectlystructureddataenteredbyprovidersinthefield.SomeintegrationworkwouldneedtobecompletedtotaketheoutputofSeentagsandestablish1540patient/providercontextbutitispossiblethatSeentagsoutputcanbepublishedasobservationsorconditions[SHR01,SHR05]totheHIX.

ReportingWheelisanotherInSTEDDprojectthathaspotentialtobeusedasatoolforgatheringobservationsfromedgedevices,howeveritisunclearifthetoolsupportsestablishingpatientcontextwhichwouldberequiredpriortoinvokingHIXoperations[HIX01,HIX03].


AnalysisofNuntiumrevealedthatisageneralpurposetoolkit,orframeworkforbridgingedgedevicedatatoapplicationsthatarewrittenbydevelopers.This,combinedwiththecurrentintegrationcapabilitiesthatNuntiumhaswithOpenMRSmeansthatitcanbeusedasagatewayapplicationtotheHIX.Nuntiumwouldn’tbeusedstandalonewiththeHIX,ratherdeveloperswouldleverageNuntiumtogatherdatafromedgedevicespriortosubmittingtotheHIX.1550

ChildCount+isbasedonRapidSMSandsupportstheconceptofcases,referrals,birthreports,andpregnancyconditions14whichmakesitanidealcandidateforsupplyinginformationtotheHIXintheformofreferralnotification[SHR23],observations[SHR05,SHR07]andencounters[SHR11,SHR13].Fromafunctionalstandpoint,itappearsthatentitiescontainedwithinCC+maptooperationsprovidedbythesharedclinicalrepositorieswithintheHIX.

OpenMRSoperatingasaconsumerapplicationalsoappearstobearelativelygoodfitasaHIXconsumer.OpenMRS’conceptsofpatient,user,encounter,observationandformmapquitenicelytothesharedservicesofclientregistry[ROL01],providerregistry[ROL03],encounterrepository[ROL25],observationrepository[ROL23],documentrepository[ROL11].

CommCareisaformbasedtoolanditsuseasaconsumerofHIXservicesdonotappeartopresent1560significantchallenge.BasedonanalysisofCommCareHQ’sCaseXMLformats,itispossibletoestablishpatientcontextbasedoncaseidentifier.OfthestructuresavailableinCommCare(basedontheAPIstoCommCare)thereferralandcaseentitiesseemmostapplicabletobesharedviathereferralrepository[ROL21]andencounterrepository[ROL25]respectively.Additionally,itappearsthatsupportforaddingZ-segmentstoaCommCarexFormsispossible,howevercareshouldbetakenonthekeyandcontentoftheseZ-segmentstoensurestructuralandsemanticinteroperability.TheexistenceofsuchextensionspointfromadataentrystandpointmeansCommCarecanbemodifiedtosupportadditionalinteractionswiththeHIX.

Ofalltheproductsreviewedforconsumerapplicationroles,noneseemedtohavesupportforconnectingandsharingdatainatransactionalmannerwithanexternalsystem.Thismeansthatbefore1570anyoftheseapplicationsare“pluggable”intotheHIXtheymustfirstundergodevelopmentofsoftwareinterfacesthatmakethemcapableofinvokingservicesontheHIX.

14ChildCount,“ChildCount+SchemaERD,”http://docs.google.com/leaf?id=0B60dZeVSrm3tYjQ3Njg5YjYtMDU4OS00N2U0LWE1ZjEtNjRmNmZiNDI0MTA3&hl=en


DataArchitectureThedataarchitectureofthesystemseekstodescribetheminimumdataelementsthatmustexistwithineachoftheserviceroles.Providersofeachserviceroleareexpectedtobecapableofstoringandconveyingtheminimumdataelements,whileserviceconsumersmustbecapableofpopulatingtheminimumdataelements.

Thedataarchitecturefocusesonstructuralinteroperabilityatadataelementlevel.Whileitdiscusses1580thesemanticinteroperabilityconsiderationsinthecontextofdataarchitecture,itdoesnotprescribesuchconstraints.

CommunicationsArchitectureonpage73discussesconveyingofthesedatastructuresusingavarietyofmessagingformats.Thissectionalsodescribessemanticinteroperabilityinmoredepth.

OverallDataModelTheoveralldatamodelisusedtodescribethestandardelementsthatarepresentinapatient’shealthrecord.Inthecontextofthesystemspecifiedinthisdocument,theoveralldatamodeldescribesthecollectivedataelementsacrosssystems.

Figure50illustratesastandardviewofdataelementsinanEHRandhighlightswhichapplicationrolesareresponsibleforthestewardshipofthosedataelements.1590

Health Issue Clinical Information Health Care Provider Individual User Access Subject

Authorization Profile

ResourceActivity

Subject Of Care Patient Plan

Clinical Plan

Clinical Guidelines & Protocols

Contact

Period of Care

< Is responsible for

< Belongs to

Subject to

Is requesting / performing >

Is used by >

< Is delineated by

Groups

< Has

< Has

< Is instantiated for

< Is derived from

Is generated by / relevant for >Belongs to >

Executed regarding >

Figure50-Relationshipbetweendataelements(ISO12967-1,2:2007)

ROL19

ROL23,ROL11

ROL25

ROL01

ROL30

ROL03

ROL17

ROL21


CommunicationsArchitecture

CommunicationsArchitectureOverviewAspartoftheanalysisforthisspecification,severalstandardswereidentifiedforuseaboveandbelowtheHIX,aswellasforusewithintheHIX’sarchitecture.

ThetypesoftransactionsanddataelementsthatflowthroughtheHIXwillvarywidely.Asno-one1600standardcanbechosentointerfacewiththeHIX,thejobofintegrationbecomesmorecomplex.ItisforthisreasonthattheCHPteamhasselectedtheuseoftheon/offramppatternforimplementingtheHIXillustratedinFigure51.

XDS.bOn-Ramp

HL7v2On-Ramp

HL7v2 Lab Result

HL7v3 On-Ramp

IHE PIX/PDQVersion 3

HIX Orchestrations / Routing

Canonical Form

Canonical Form

Canonical Form

IXS Off-Ramp

Mirth Connect

IXS

IHE XDS.b

CDAEncounter Report

DM-MI Off-Ramp

Open DM-MI

DM

-MI

Can

onic

al F

orm

Figure51-On/OffRampingPattern


ThefigureillustratesaHIXthatacceptsclientregistry[ROL01]requestsfromclientsusingIHEPIX/PDQ.ThisHIXalsocontinuestoacceptlegacylabresultsusingHL7v2interfacesviatheHIX,andencountersummaryreportsinCDAoverXDS.b.

Allofthesetransactionshavethesamerequirement;theymustsomehowberoutedtotheclientregistry[ROL01]forthejurisdiction.Ratherthanwritingthreedifferentorchestrations(oneforeachof1610thestandards),theHIXmessageservice[ROL13]“normalizes”themessagetoacanonicalforminaprocessknownason-ramping.

ThismeansthatallmessagesthataretobeprocessedbytheHIXorchestrationlayer[ROL27]areinthesameformat.Commonorchestrations(likevalidatingapatientorprovider)canbewrittenonceagainstthiscanonicalform.WhenevertheHIXwishestosolicitorsendamessagetoaclinicalrepository,itconstructstherequestinitscanonicalform(ratherthantheformatoftherepository).

Throughaprocessknownasoff-ramping,theHIXmessagingservice[ROL13]“de-normalizes”themessageintowhateverstandardthedestinationrepositoryrequires.Thismeansthatrepositoriescanbedeprecated,upgradedorchanged(forscalingreasons)withoutchangingthecodefortheHIX.

Thispatternisrecommendedforthefollowingreasons:1620

1. ItensuresthatcommonHIXorchestrationsarewrittenonceanddonotneedtobechangedbasedontheinboundmessageformat,

2. ItallowsclinicalrepositoriestobereplacedorupgradedwithnochangetotheHIX’sorchestrations,merelytheon/off-rampsfortheaffectedservice,

3. Normalizingallmessagestoasinglecanonicalformmeansthatdatawarehousingandstatisticalanalysiscanbeperformedonacommonsetofstructures

Iftheon/offrampingpatternusedtoimplementtheHIX,thefocusbecomeswhatformatthecanonicalformwilltake.Thekeytoasuccessful,longlastingimplementationofanon/offrampingpatternisastable,consistentrepresentationofclinicaldatathatisbothall-encompassingandfutureready.

Whileitispossibletodesignsuchacanonicalform,theCHPteamdecidedthatleveragingotherworks1630currentlyavailablewouldbemoresuitableandtakethefocusawayfromdesigningacanonicalformtoimplementingit.

Thereweretwocandidatestandardsidentifiedforthecanonicalmodel:

• TheHL7ReferenceInformationModel(RIM),• OpenEHRReferenceModel(RM)

Eitherofthesecandidateshavethecapacitytorepresentclinicaldatainaconsistentmanner.TheCHPteamisrecommendingtheuseofRIMforseveralreasons:

1. ThereisaRIMbasedITSwhichprovidesexamplesofhowRIMstructurescanbeserializedintoXML,meaningthestructuresarereadilyavailable,


2. TheCHPteamhasmoreexperiencewithHL7andtherewasnottimetolearntheOpenEHR1640standardtoasufficientlevelthattheteamcouldpresumeittobefitforthispurpose,

3. Aseriesoftoolsexistforautomaticallycreatingtransformsto/fromHL7v3(andderivativestandardslikeCDA,PIX/PDQv3)totheRIM.

Example1illustratesanexampleofon-rampingarequestinHL7v3totheRIMandthende-normalizingittoOpenDM-MI’srepresentationforlookupoftheclientsECID.Thissampleisprovidedforillustrativepurposes,thisspecificationtalksaboutstandardsforclientcommunicationslaterinthissection.

Example1-On/Offrampingexample

Step1:TheclientsendsarequestforapatientsummarytoaHIXon-ramp.Notethepatientidentifierthatweneedtovalidate.TheXPaththisthiselementis:/hl7:COMT_IN100000CA/hl7:controlActEvent/hl7:recordTarget/hl7:patient1/hl7:id<COMT_IN100000CA ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"> <id specializationType="II.TOKEN" root="ED852DDC-BA48-4E59-97DB-68B333054477" /> . . . <controlActEvent classCode="CACT" moodCode="EVN"> . . . <recordTarget typeCode="RCT" contextControlCode="AP"> <patient1 classCode="PAT"> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M" use="BUS"/> <patientPerson classCode="PSN" determinerCode="INSTANCE"> <name specializationType="PN.BASIC" use="L"> <given partType="GIV">Mosa</given> <family partType="FAM">Muntabe</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1" /> <birthTime specializationType="TS.DATE" value="19920203" /> </patientPerson> </patient1> </recordTarget>

Step2:TheOn-Rampwillexecuteantransformthattransformsthemessagetothenormalform.Thisnormalformmessageispassedtothegeneric“resolvepatientECIDs”orchestrationandissimilarinstructureforallinteractionswiththeHIX.TheXPathtothepatientidentifierelementisnow:/hl7:Message/hl7:controlAct/hl7:participation/hl7:role/hl7:id<hl7:Message xmlns:hl7="urn:hl7-org:v3" xmlns:ext="urn:marc-hi:ca/hial"> <hl7:id specializationType="II.TOKEN" root="ED852DDC-BA48-4E59-97DB-68B333054477" /> . . . <hl7:controlAct classCode="CACT" moodCode="EVN"> . . . <hl7:participation typeCode="RCT" contextControlCode="AP"> <hl7:role classCode="PAT"> <hl7:id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M"


use="BUS" /> <hl7:player classCode="PSN" determinerCode="INSTANCE"> <hl7:name use="L"> <given>Mosa</given> <family>Muntabe</family> </hl7:name> <hl7:administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1" /> <hl7:birthTime value="19920203" /> </hl7:player> </hl7:role> </hl7:participation> . . .

Step3:TheHIX’sresolveorchestrationwishestoresolvetheidentifiertoanECID.TheorchestrationshouldnotassumewhattechnologyisdeployedfortheEMPIandconstructsacanonicalmessagethatinstructstheHIXmessaginglayer[ROL13]toexecuteCR01.TheHIXorchestrationdoesn’tknow(anddoesn’tcare)whatsoftwarepackagewillperformtheresolutionandpassesthemessagetotheoff-ramp(nb:inabusthiswouldbeapublishratherthanacall)<hl7:Message tag="CR01" xmlns:hl7="urn:hl7-org:v3" xmlns:ext="urn:marc-hi:ca/hial"> . . . <hl7:controlAct classCode="CACT" moodCode="EVN"> . . . <hl7:queryEvent> <hl7:queryId root="6360C7AE-FFEF-42dd-B30F-B36EEB9FB942" /> <hl7:parameter> <hl7:parameter ext:semText="clientIDPub"> <hl7:value root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M" use="BUS"/> </hl7:parameter> </hl7:parameter> </hl7:queryEvent> </hl7:controlAct> </hl7:Message>

Step4:Theoff-rampfortheCR01operationexecutesthetransformthatiscurrentlyconfigured.Theoff-rampthensendstheresultofthattransformationtotheclientregistryservice(inthiscaseOpenDM-MI).<web:getEUID xmlns:web="http://webservice.index.mdm.sun.com/" xmlns:hl7="urn:hl7-org:v3"> <systemCode>Regional mHealth Gateway Data Centre</systemCode> <rootId>91EF4EA5-C1EA-4015-B2D8-D1565127D5C2</rootId> <queryId>6360C7AE-FFEF-42dd-B30F-B36EEB9FB942</queryId> <clientExtension>494825-231102-2022M</clientExtension> <clientRoot>1.3.6.1.4.1.33349.3.1.2.1.0</clientRoot> </web:getEUID>

IfthejurisdictiononedaydecidedtouseOpenEMPIforaclientregistry,itwouldonlyneedtochangethetransformexecutedinstep4ofthisexampletoconstructanappropriatemessage.Thisarchitecture1650allowsajurisdictiontointegratetechnologiesbehindtheHIXusinganyformattheywish.Italsotheoreticallyallowsjurisdictionstoacceptmessagesinanymessagingformatthatcanbemappedtothecanonicalform,althoughthisisdiscouraged.


Figure52illustratesthesystemusingtheon/offrampingpattern(nb:thisisthesamearchitectureasillustratedinFigure1onpage11)

Clinical Repositories

HIX Security / AuditServices

Consumer Applications

SMS Gateway IVR Gateway CDA API HL7v3 API

Edge Devices

“Dumb” Phone Smartphone Netbook PC

Orchestration[ROL27]

FederatedSecurity[ROL17]

CertificateServices

AuditRepository[ROL15]

Demographic Registries

Client Registry[ROL01]

Provider Registry[ROL03]

Facilities Registry[ROL05]

Obs Repository[ROL23]

Doc. Repository[ROL11]

Cond. Repository[ROL19]

CHW Clinicians Physicians Healthcare Workers

Terminology Services[ROL07]

Referral Repository[ROL21]

Enc. Repository[ROL25]

SHR[ROL09]

Messaging[ROL13]

Onramps

PIX/PDQv3 CDA/XDS.b HL7v2/MLLP CDA/HL7v3

Offramps

HL7v3 / SOAP CDA / XDS.b HL7v2/MLLP OpenMRS / REST

CDAHL7v3HL7v2

IHE PIX/PDQIHE XDS.bOpenEHR1

HL7v3 RIM XMLOpenEHR RM1

HL7v3 RIM XMLOpenEHR RM1

IHE PIX/PDQHL7v3

OMG IXS

Other Canonical Format

Other Canonical Format

DMMI SOAP APIOpenMRS REST

FREDOther SOAP

Other REST API

IHE XDS.bHL7v3HL7v2

OpenMRS RESTOther SOAPOther REST

WebDAV

SMSIVR

IPC / API / SDK

IETF RFC-3881IHE ATNA

OpenIDSAML

WS-Trust

Syslog Audits

Figure52–Serviceroleswiththeon/offrampingpatternapplied

ThediagramalsoillustratesthecandidatestandardsthatwereidentifiedaspartoftheanalysisofcommunicationsprotocolswiththeHIX.


ConsumerApplications1660Becausethenumberofconsumerapplicationsaccessingthesystemispotentiallyvast,theroleofwell-definedcommunicationsinterfacesiskeytofacilitatinginteroperabilitynotjustbetweentheconsumersandtheHIX[ROL13]buttheconsumerandotherconsumers(viatheHIX).

AsstatedinConsumerApplicationRolessectioninsoftwarearchitectureonpage67,therolesthatsoftwarepackageschoosetoconsumedependsolelyontheiruseinthefield.ThissectionwilldiscusstheanalysisofseveralstandardsbasedcommunicationsprotocolsthatcanbeusedbyconsumerapplicationsaccessingtheHIX.

Theanalysisforsuitabilityofeachstandardisbasedonthecurrentversionofthestandard,usingavailabledocumentation,sampleinstancesandinterfacecontracts.Roadmaporfutureenhancementswerenotconsideredforthisanalysis.1670

Eachstandardinterfacewascomparedforsuitabilitybasedonthefollowingcriteria:

• AbilitytoinvoketherequiredfunctionalityspecifiedintheSoftwareArchitectureonpage12,• AbilitytoconveythenecessarydataelementsidentifiedinDataArchitectureonpage72andthe

usecasestoriesdocument,• StandardizationofdataelementsandnumberofZ-segments,• Messagingsemanticsanddefinitionofstandardvocabulary,• Existingopensourceimplementations,frameworksorlibraries,

Theresultofthisanalysisisgroupedbyconsumerrolethatasoftwarepackagewouldimplement.

ConveyingthenecessarydataelementstotheHIXisperhapsthemostimportantcharacteristicofafront-linecommunicationsprotocol.Becausetheconsumerapplication(s)willbecommunicatingwitha1680systemthatmaytransformorforwarddatatoothersystems,themessagesbetweentheconsumersandHIXmustcontainanydataelementthatanothersystemmayuse.

ClientRegistryServiceConsumer[ROL02]Consumerapplicationactingintheroleofaclientregistryserviceconsumer,arecapableofinvokingfunctionalitythatqueries,resolves,registersorupdatespatientdemographicinformation.

Thefollowingcandidatestandardshavebeenidentifiedforanalysisintheclientregistryserviceconsumer[ROL02]role:

• IHEPIX/PDQv2• IHEPIX/PDQv3• HL7v3PatientAdministrationMessages1690• OMGIXS(IdentityCross-ReferenceService)

Thecandidatestandardswerecomparedagainstthedataandfunctionalityrequirementsforaclientregistryconsumer.TheresultofthisanalysisisoutlinedinTable15.


Table15-Standardsanalysisforclientregistryconsumers[ROL01]

PIX/PDQv2 PIX/PDQv3 HL7v3PRPA IXSCR01–ResolveIdentifiers X X X *CR03–PatientDemographicsQuery X X X *CR05–RegisterClient X X X *CR08–UpdateClient X X X *Conveysmandatorydata † X X *StandardizationofVocabularies X X X *ExistingOSSFrameworks/Tools Many Moderate Few Few†-Mandatoryfieldsaresupported,howeversomeoptionalfieldshavenoplaceinthemessagestructure*-Additionalworkonstandardizingdataelements,entitytraitsandvocabularymustbeperformedpriortouse

Eachofthesestandardsidentifiesdifferentoperation(orinteractions)whichprovidethefunctionalityidentifiedfortheclientregistry[ROL01].Table16mapstheoperationIDusedbythisdocumenttotheinteractionsusedforeachofthestandards.

Table16-Operationstomessagemap

PIX/PDQv2 PIX/PDQv3 HL7v3PRPACA IXSCR01 QBP^Q23 PRPA_IN201309UV02 PRPA_IN101105CA FindIdentitiesByTraitsCR03 QBP^Q22 PRPA_IN201305UV02 PRPA_IN101103CA FindIdentitiesByTraitsCR05 ADTÂ04 PRPA_IN201301UV02 PRPA_IN101201CA RegisterEntityWithIdentityCR07 ADTÂ31 PRPA_IN201301UV02 PRPA_IN101001CA CR08 ADTÂ04 PRPA_IN201302UV02 PRPA_IN101204CA UpdateEntityTraitValuesCR10 ADTÂ31 PRPA_IN201302UV02 PRPA_IN101002CA 1700

IntegratingtheHealthEnterprise(IHE)isavendorcommunitythattakesexistingstandardsandconstrainsthemtoassistvendorsinachievinginteroperability.PIX/PDQ(PatientIdentityCross-ReferencingandPatientDemographicQuery)identifiesasuiteofmessagesthatcanbeusedtoquerypatientdemographicsandregisterpatients.CurrentlythereareversionsofPIX/PDQ;oneusingHL7v2.5messagingandanotherusingHL7v3messaging.

IHEhasconstrainedHL7v2messagingintheITInfrastructureTechnicalFramework(ITITF)15andlimitstheuseofZ-Segments.FurthermoretheITITFidentifieshowanHL7v2messageshouldbepopulated.Example2illustratesasamplePIXquery[CR01],andhighlightsthepatientidentifierwhichistoberesolved.

15IHE,“ITInfrastructureTechnicalFrameworkVol.2a,”http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2a_FT_2011-08-19.pdfpp.40-72,pp.149-167


Example2-PIXQuery[CR01]1710

MSH|^~\&|OPENMRS_DEPLOYMENT|OPENMRS|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20111111144546||QBP^Q23^QBP_Q21|658598754|P|2.5||||||| QPD|IHEPIXQuery|Q231235421946|494825-231102-2022M^^^NHA_PATCARD&1.3.6.1.4.1.33349.3.1.2.1.0&ISO^PI|^^ÊCID&1.3.6.1.4.1.33349.3.1.2.1.3.0.43&ISO RCP|I|

TheresultofthisqueryisoutlinedinExample3,withtheresultPID(patientidentification)segmenthighlighted.

Example3-PIXResponse[CR02]

MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|PACS_FUJIFILM|FUJIFILM|20090223154549-0500||RSP^K23|OpenPIXPDQ10.243.0.65.19766751187011|P|2.5 MSA|AA|1235421946 QAK|Q231235421946|OK QPD|IHEPIXQuery|Q231235421946|494825-231102-2022M^^^NHA_PATCARD&1.3.6.1.4.1.33349.3.1.2.1.0&ISO^PI|^^ÊCID&1.3.6.1.4.1.33349.3.1.2.1.3.0.43&ISO PID|||B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C^^ÊCID&1.3.6.1.4.1.33349.3.1.2.1.0.43&ISO^PI||~^^^^^^S

PDQisusedwhenaconsumerapplicationwishesto“search”foraclientbasedonasetofavailabledemographics.Example4illustratesasamplequeryforalookupofanyonenamed“MosaMuntabe”,queryparametersarehighlighted.

Example4-SamplePDQRequest[CR03]

MSH|^~\&|OPENMRS_DEPLOYMENT|OPENMRS|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20111111144546||QBP^Q23^QBP_Q21|658598754|P|2.5||||||| QPD|Q22^Find Candidates Example^HL7|Q2128|@PID.5.1.1^[email protected]^[email protected]^F RCP|I|10^RD1720

TheresponseforthisoperationisshowninExample5.Thedemographicinformationishighlighted.

Example5-SamplePDQresponse[CR04]

MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|OPENMRS DEPLOYMENT|OPENMRS|20111111141518-0500||RSP^K22|OpenPIXPDQ10.243.0.65.19770811493153|P|2.5 MSA|AA|7965847682428535543 QAK|4870964660388599565096567512128|OK||6|6|0 QPD|Q22^Find Candidates Example^HL7|Q2128|@PID.5.1.1^[email protected]^[email protected]^F PID|1||494825-231102-2022M^^^NHA_PATCARD&1.3.6.1.4.1.33349.3.1.2.1.0&ISO^PI~B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C ^^ÊCID&1.3.6.1.4.1.33349.3.1.2.1.43&ISO^PI ||MUNTABE^MOSA||19920203|F|||^^Local Village^SA^7321


AnalysisthedatastructureofPIXandPDQversion2messagesshowsthatitcanconveyallrequireddataelementsspecifiedfromtheusecasestories,howevertheredoesnotappeartobeaPIDsegmentdefinedforpatienttelecommunicationsaddresses(phonenumbers,etc…)whichmaycauseissueundercertaincircumstances.Additionally,PIX/PDQversion2istransportedviaHL7MLLPwhichmayrequireadditionalimplementationstepsbasedontheintegrationengineusedtodeploytheHIXmessagingservices[ROL13].

BecausePIX/PDQisbasedonHL7v2,awidevarietyofv2toolscanbeusedtocommunicateusingit,and1730IHEconstrainsHL7v2messagesthataresentto/fromtheserviceprovider,meaningmessagesemanticsarewelldefined.

PIX/PDQversion3isdefinedintheIHEITITFVol2b16documentandusesHL7v3messaging.Example6isasnippetofaPDQv3[CR03]querythatsolicitstheclientregistry[ROL01]forMosa’sdemographicinformation(equivalentquerytoExample4)

Example6-SamplePDQv3request[CR03]

<PRPA_IN201305UV02 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"> <id root="1.2.840.114350.1.13.0.1.7.1.1" extension="44506" /> . . . <controlActProcess classCode="CACT"> <code code="PRPA_TE201305UV02" /> <queryByParameter> <queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204" /> <statusCode code="new" /> <initialQuantity value="1" /> <matchCriterionList> <minimumDegreeMatch> <value xsi:type="INT" value="100" /> <semanticsText>Degree of match requested</semanticsText> </minimumDegreeMatch> </matchCriterionList> <parameterList> <livingSubjectAdministrativeGender> <value code="F" codeSystem="2.16.840.1.113883.5.1" /> <semanticsText>LivingSubject.administrativeGender</semanticsText> </livingSubjectAdministrativeGender> <livingSubjectName> <value use="L"> <given partType="GIV">Mosa</given> <family partType="FAM">Muntabe</family> </value> <semanticsText>LivingSubject.name</semanticsText> </livingSubjectName> </parameterList> </queryByParameter> </controlActProcess> </PRPA_IN201305UV02>

16IHE,“ITInfrastructure,TechnicalFrameworkVol.2b,”http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Rev8-0_Vol2b_FT_2011-08-19.pdf.Pp.152-227


Asnippetoftheresponseforthisquery[CR04]isillustratedinExample7(thisisequivalenttoExample5).

Example7-SamplePDQv3response[CR04]1740

<?xml version="1.0" encoding="UTF-8"?> <PRPA_IN201306UV02 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"> <id root="1.2.840.114350.1.13.999.238" extension="55789"/> . . . <acknowledgement> <typeCode code="AA"/> <targetMessage> <id root="1.2.840.114350.1.13.0.1.7.1.1" extension="35423"/> </targetMessage> </acknowledgement> <controlActProcess classCode="CACT" moodCode="EVN"> <code code="PRPA_TE201306UV02" codeSystem="2.16.840.1.113883.1.6"/> <subject typeCode="SUBJ"> <registrationEvent classCode="REG" moodCode="EVN"> <id nullFlavor="NA"/> <statusCode code="active"/> <subject1 typeCode="SBJ"> <patient classCode="PAT"> <statusCode code="active"/> <patientPerson> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M"/> <name> <given>Mosa</given> <family>Muntabe</family> </name> <telecom value="tel:+1-795-555-4745" use="MP"/> <administrativeGenderCode code="F"/> <birthTime value="19920203"/> <addr> <city>Local Village</city> <state>SA</state> </addr> <asOtherIDs classCode="PAT"> <id root="1.3.6.1.4.1.33349.3.1.2.1.0.43" extension="B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C"/> </asOtherIDs> </patientPerson> </patient> </subject1> </registrationEvent> </subject> <queryAck> <queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204" /> <queryResponseCode code="OK"/> <resultTotalQuantity value="1"/> <resultCurrentQuantity value="1"/> <resultRemainingQuantity value="0"/> </queryAck> <queryByParameter> <queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204" /> <statusCode code="complete"/> . . . </queryByParameter> </controlActProcess> </PRPA_IN201306UV02>


AswithPIX/PDQv2,theHL7v3versionoftheIHEprofileconstrainsoptionalityandexplicitlydefinesdataelementsthataretobeconveyed.AllrequiredandoptionaldataelementsofapatientcanberepresentedinaPDQv3responseandPIXv3identityfeed.

SinceHL7v3messagingisuseditispossibletotranslate/transformaninboundPIX/PDQv3messagetootherRIMbasedformatssuchasCDAusingXMLtechnologies.Additionally,HL7v3itselfspecifiesvocabularydomainsthatarepermittedforuseonelementsusedwithinthemessagewhichmeanssemanticinteroperabilityisattainable.

ThereisanaddedoverheadofsendingXMLmessagetoandfromtheHIX,howeverXMLiswellsuitedforcompression17whichmayovercomebandwidthlimitations.1750

TheHL7v3patientadministrationdomain(PRPA)canalsobeusedoutsideofPIX/PDQv3messaging.Universalstandards(likethoseusedbyIHEPIX/PDQv3)canbeleveragedaswellasconstrainedlocalversions.Inthisspecificationthepan-CanadianClientRegistryspecificationwasusedforcomparison.

Illustratesasamplefindcandidatesmessageusingpan-CanadianHL7v3messagingspecification.Note:someofthetransportwrapperinformationhasbeenexcludedfromthesample.

Example8-SampleHL7v3findcandidatesquery[CR03]

<PRPA_IN101103CA ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"> <id specializationType="II.TOKEN" root="C6B073FD-9849-473B-9B26-035799934161" /> . . . <controlActEvent classCode="CACT" moodCode="EVN"> <id specializationType="II.BUS" root="33F126F5-FEB0-415E-A785-6DA0A21B9749" /> <code code="PRPA_TE101103CA" codeSystem="2.16.840.1.113883.1.18" /> <statusCode code="completed" /> <author typeCode="AUT" contextControlCode="AP"> <time value="201111101036" /> <assignedEntity1 classCode="ASSIGNED"> <id root="1.3.6.1.4.1.33349.3.1.2.1.1" extension="0009" assigningAuthorityName="A Regional CHW Authority" /> <id root="1.3.6.1.4.1.33349.3.1.2.1.1.2" extension="1093" assigningAuthorityName="National Health Worker Identifier Registry" /> <assignedPerson classCode="PSN" determinerCode="INSTANCE"> <name specializationType="PN.BASIC" use="L"> <given partType="GIV">Grace</given> <family partType="FAM">Gillmont</family> <prefix partType="PFX">Mrs</prefix> </name> </assignedPerson> </assignedEntity1> </author> <queryByParameter> <queryId root="6471B1B0-238D-4ADB-8452-FAD470EA3856" /> <parameterList> <administrativeGender>

17C.Augeri,B.Mullins,D.Bulutoglu,R.Baldwin,andL.BairdIII,“AnAnalysisofXMLCompressionEfficiency,”http://xml.coverpages.org/AugeriExpCS-2007.pdf.


<value code="F" codeSystem="2.16.840.1.113883.5.1" /> </administrativeGender> <personName> <value specializationType="PN.SEARCH" use="SRCH"> <family partType="FAM">Muntabe</family> <given partType="GIV">Mosa</given> </value> </personName> </parameterList> </queryByParameter> </controlActEvent> </PRPA_IN101103CA>

ThestructureofthismessageisnearlyidenticaltotheIHEPDQv3message(Example6)whichcanbemisleading.FormalGAPanalysisperformedpreviouslybytheMohawkteamhasrevealedthatthestandardshavesignificantdifferencesandmappingbetweenthetwohasseveralcaveats.1760

TheresponseofthisrequestisprovidedinExample9.Demographicinformationhasbeenhighlighted.

Example9-SampleHL7v3findcandidatesresponse[CR04]

<PRPA_IN101104CA ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <id specializationType="II.TOKEN" root="F32ECBFB-97B5-4AE8-B917-5004147C5DF5"/> . . . <acknowledgement typeCode="AA"> <targetMessage> <id specializationType="II.TOKEN" root="fdB073FD-9849-473B-9B26-035799934161"/> </targetMessage> </acknowledgement> <controlActEvent classCode="CACT" moodCode="EVN"> <id specializationType="II.BUS" root="2C76B727-1038-406A-A22C-904BABE03610"/> <code code="PRPA_TE101104CA" codeSystem="2.16.840.1.113883.1.18"/> <statusCode code="completed"/> <subject typeCode="SUBJ" contextControlCode="ON" contextConductionInd="false"> <registrationEvent classCode="REG" moodCode="EVN"> <statusCode code="active"/> <subject typeCode="SBJ" contextControlCode="AN"> <identifiedEntity classCode="IDENT"> <id root="1.3.6.1.4.1.33349.3.1.2.2.3.0" extension="13"/> <id root="1.3.6.1.4.1.33349.3.1.2.1.0.43" extension="B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C"/> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M"/> <identifiedPerson classCode="PSN" determinerCode="INSTANCE"> <name> <given partType="GIV">Mosa</given> <family partType="FAM">Muntabe</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/> <birthTime specializationType="TS.DATETIME" value="19920203"/> <addr> <city partType="CTY">Local Village</city> <state partType="STA">SA</state> </addr> </identifiedPerson> . . . </identifiedEntity> </subject> . . .


</registrationEvent> </subject> <queryAck> <queryId root="6471B1B0-238D-4ADB-8452-FAD470EA3856"/> <queryResponseCode code="OK"/> <resultTotalQuantity specializationType="INT.NONNEG" value="1"/> <resultCurrentQuantity specializationType="INT.NONNEG" value="1"/> <resultRemainingQuantity specializationType="INT.NONNEG" value="0"/> </queryAck> <queryByParameter> <queryId root="6471B1B0-238D-4ADB-8452-FAD470EA3856"/> . . . </queryByParameter> </controlActEvent> </PRPA_IN101104CA>

Theuseofalocalized(oruniversal)variantofHL7v3providesseveraladvantages.NamelythatHL7v3’spatientadministrationdomainiswelldefinedandvocabularyusedinthemessagepromotessemanticandstructuralinteroperability.AllofthemandatoryandoptionaldataelementsforapatientcanbeconveyedusingHL7v3messagingandthemessagescarryenoughinformationtoberoutedthroughtheHIXwithoutmissingdata.

OnlyabriefanalysisofIXScouldbeperformedbytheCHPteamatMohawk.ThishighlevelanalysisrevealsthatIXSisagenericentitymatching/cross-referencestandardwhichcanbelooselymappedto1770PIX/PDQ(asmentionedbyOMGintheirstandard18).BecauseIXSisagenericspecification(ratherthandomainspecifictopatientadministration),jurisdictionswillneedtofirstidentifyentitytypesandtraitsthatcanbeusedforsearchofpatientrecords(oradoptaseriesofalreadydefinedtraits).AseriesofEMPIanalysishasbeenperformedbytheMirthMatchcommunity19.

Afterdefinitionofentitiesandidentifyingtraitsarespecified,consumerapplicationsmakequeryrequestsusingtheFindIdentitiesByTraitsmethodontheIXSManagementAndQueryInterface.UnfortunatelytheteamwasunabletoacquireXMLsamplesofthisfunctionallytobeincludedinthisspecificationbutexamplesusingtheJavalanguagecanbefoundontheMirthMatchwebsite20.

UsingIXSasa“last-mile”standardwouldrequireajurisdictiontocarefullyestablishentitytypes,andtraitsaswellasvocabulariesforeachofthetraitvalues.Furthermore,sinceIXSrequestsarebeing1780routedthroughtheHIX(andontootherservicesbehindtheHIX),greatcareshouldbetakeninensuringthatthedatawithinanIXSmessagecanbemappedtoanormalizedformandtothemessagingformatusedbytheregistriesbehind.

ThisspecificationrecommendsthatuseofanXMLbasedHL7v3standardbeadoptedbyjurisdictionswishingtorouteconsumerapplicationrequestsforpatientdemographicsthroughtheHIX.SinceHL7v318OMG,“IdentityCross-ReferenceService(IXS),”http://www.omg.org/spec/IXS/1.0.1/PDF/p.5919Mirth,“eMPIRequirementFeedback,”http://www.mirthcorp.com/community/wiki/display/EIS/eMPI+Requirement+Feedback.20Mirth,“MirthMatchClientWebServiceTutorial”,http://www.mirthcorp.com/community/wiki/display/EIS/Mirth+Match+Client+Tutorial+and+Examples.


canbecomplex,thespecificrecommendationisforuseofIHEPIX/PDQv3forpatientdemographicsqueries.Thisrecommendationisbasedonthefollowing:

1. IHEPIX/PDQv3supportsalldataelements(mandatoryandrequired)identifiedbythedataanalysiscontainedintheusecasestoriesdocument,

2. ThereiswidesupportforIHEprofilesfromvendors,andseveralopensourcesoftware1790implementationsexist,

3. HL7v3messagingframeworkslikeHL7JavaSIG,andEverestcanbeusedtofacilitatetheconstructionofPIX/PDQv3messages,

4. PIX/PDQv3iswelldefinedbyIHEintheITITFVol.2b,andhasapredefinedsetofconformancetestswhichcanbeusedforcertificationbyjurisdictions,

5. IHEstandardsareavailablepubliclyontheinternetandithasalargecommunityofadopters6. TheIHEPIX/PDQv3messagingmodelcaneasilybemappedtotheHL7RIM(therecommended

normalizedformfortheHIX)

ClinicalRegistriesConsumersClinicalregistriesconsumersare1800

Thereareseveralconsumerrolesidentifiedforthe“clinicalregistries”group,theyare:

• ROL10–SharedHealthRecordConsumer• ROL12–DocumentRepositoryConsumer• ROL20–HealthConditionsRepositoryConsumer• ROL22–ReferralRepositoryConsumer• ROL24–ObservationsRepositoryConsumer• ROL26–EncounterRepositoryConsumer• ROL31–CarePlanRepositoryConsumer

Thefollowingstandardshavebeenidentifiedforconsuminghealthservices:

• HL7Version2.51810• HL7ClinicalDocumentArchitecture(CDA)Revision221• HL7Version3• IHECross-EnterpriseDocumentSharing(XDS.b)22

OpenEHRwasidentifiedasacandidatestandardforthecommunicationofdatawiththeHIX,howeveradditionalanalysisisrequiredbeforerecommendationsaboutitssuitabilitycanbereported.

ThecandidatestandardswerecomparedagainsteachoftheclinicalregistryoperationsandtheresultshavebeensummarizedinTable17.

21AlthoughCDAisnotcapableof“invoking”operations,itisincludedasacandidatebecauseitcaneasilybewrappedinanynumberofcontainersandcanconveystructuredclinicalinformation.22XDS.bisnottechnicallyastandard,butawidelyadoptedindustryspecificationforsharingclinicaldocuments


Table17–Standardsanalysisforclinicalregistryconsumers

HL7v2.5 HL7CDA HL7v3 IHEXDS.bSHR01–CreateObservation X * X SHR03–QueryObservations ? † X SHR05–RecordHealthCondition X * X SHR07–UpdateHealthCondition X * X SHR09–QueryHealthConditions ? † X SHR11–RecordClinicalEncounter X * X SHR13–UpdateClinicalEncounter X * X SHR15–QueryClinicalEncounter X † X SHR17–RecordCarePlan ? * X SHR19–QueryCarePlans ? † X SHR21–GetClinicalSummary ? † X DR01–StoreDocument X * X XDR03–QueryAvailableDocuments X X XDR05–GetClinicalDocument X † X XConveysmandatorydata X X X StandardizationofVocabularies ? X X XExistingOSSFrameworks/Tools Many Moderate Few Moderate†-Cannotbeusedasrequest,butissuitableasaresponse*-Canconveynecessaryclinicalinformationbutcannot“invoke”?–Standardappearstosupportthisconceptbutconcreteexamplescouldnotbefound

HL7Version2.5representsacollectionstructuredmessagesthatarecapableofexchangingclinicaldata1820andnotifyingothersystemsofevents.HL7iswidelydeployedacrosshealthenterprisesandhasawidecoverageofclinicaldomains.Becauseofitsmaturitymanycommercialandopensourcetools,frameworksandsoftwarepackagesareavailablefordeveloperstoleverage.

HL7messagesareidentifiedbythemessageeventtypewhichdefinesamessagingstructurecomprisedofsegmentgroups,segments,components,anddatatypes.

AnalysisofHL7Version2.5messagesrevealsthattheyaredesignedprimarilyforitra-organizationpurposessuchashospitaladmissionsandlaboratoryreports.Forexample,considerthePV1-7(patientvisit/attendingdoctor)segment.ThissegmentisidentifiedasdatatypeXCNandhasthefollowingstructure:

<ID (ST)>^<FAMILY NAME (ST)>^<GIVEN NAME (ST)>^<MIDDLE INITIAL OR NAME (ST)>^<SUFFIX(ST)>^<PREFIX (ST)>^<DEGREE (ST)>^<SOURCE TABLE (IS)>^<ASSIGNING AUTHORITY (HD)>^<NAME TYPE (ID)>^<IDENTIFIER CHECK DIGIT (ST)>^<CHECK DIGIT SCHEME>^<IDENTIFIER TYPE (IS)>^<ASSINGING FACILITY (HD)>

1830

Thisstructuresufficesforrepresentingphysicianswithinahospitalbutlackstheabilitytoreferencethedomain(orOID)oftheidentifier.ThisdatacanbeplacedintoPV1-7.10howeverthisstructureis


intendedtoconveytheidentifieroftheassigningauthority(orlicensingauthority,documentationisunclear).CommonexamplesofPV1-7datatakenfromHL7referencetable0010-PhysicianID:

1234^WEAVER^TIMOTHY^P^^DR 3456^ROSZEK^JEANETTE^G^^DR 5678^BAXA^TIMOTHY^P^^DR 7890^CHAVEZ^JULIO^^^DR 9012^JIANG^WEI^^^DR

ThiscombinedwiththecapabilityofextensionsthroughZ-segmentsmeansthatimplementationsofHL7v2.5arevariedandsemanticandsyntacticinteroperabilitybetweensystemsinHL7v2.5mayrequireintegrationtestingwitheachconnectionpoint.

HL7CDAisanHL7v3derivedstandardthatusestheHL7v3RIMfordescribingthestructuresitcontains.CDAisadocumentbasedstandardwhichmeansthatitdoesnothavetheabilitytoinitiateoperations,1840nordoesithavethecapabilitytofilterqueries.Itcan,however,becombinedwithother“wrapper”protocolsandstandardstotransportandsolicitinteractionwithsystems.ApplicablewrapperstandardsrangefromcomplexhealthstandardssuchasIHEXDS.bandHL7v3tosimpleSOAPandRESTstyleinterfaces,evenHL7v2documentmanagementmessagescanbeusedtotransportCDAinstances(MDM^T02).

CDAalsosupportstheconceptoftemplateswhichcanbeusedtopredefineelementswithinCDAinstancesthatmustbepresent,orfixedtospecificvalues.UsingtoolssuchasModelDrivenHealthTools23allowjurisdictionstoconstrainthepureHL7CDAspecificationandcreatetemplatesalongwithJavaAPIstogenerateCDAinstancesforthosetemplates.

Example10illustratesasnippetofanHL7CCD(ContinuityofCareDocument)representingafieldreport1850fromaCHWthathasobservedthataclientispregnant.

Example10-SampleCCDDocument

<ClinicalDocument xmlns="urn:hl7-org:v3">

<realmCode code="US"/> <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <templateId root="2.16.840.1.113883.3.27.1776" assigningAuthorityName="CDA/R2"/> . . . <id root="1.3.6.1.4.1.33349.3.1.2.2.3.2" extension="32587"/> <code code="34133-9" displayName="Summarization of episode note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <title>CHW Field Observations</title> <effectiveTime value="20111110"/> <recordTarget> <patientRole> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M"/> <telecom value="+1 203 4958473"/>

23OHT,“ModelDrivenHealthTools,”https://www.projects.openhealthtools.org/sf/projects/mdht/.


<patient> <name> <given>Mosa</given> <family>Muntabe</family> </name> <administrativeGenderCode code="F" displayName="Female" /> <birthTime value="19920203"/> </patient> </patientRole> </recordTarget> <author> <time value="20111110"/> <assignedAuthor> <id root="1.3.6.1.4.1.33349.3.1.2.1.1" extension="0009" assigningAuthorityName="A Regional CHW Authority"/> <assignedPerson> <name> <given>Grace</given> <family>Gillmont</family> </name> </assignedPerson> </assignedAuthor> </author> <component> <structuredBody> <component> <section>

<code code="11450-4" codeSystemName="LOINC"

codeSystem="2.16.840.1.113833.6.1" displayName="Problem list"/> <title>Problems</title> <text> . . . </text> <entry typeCode="DRIV"> <act classCode="ACT" moodCode="EVN"> . . . <entryRelationship typeCode="SUBJ" inversionInd="false"> <observation classCode="OBS" moodCode="EVN" negationInd="false"> <id root="FBB577C2-DBC0-4ba0-B25B-97FE763AC29F"/> <code code="64572001" codeSystemName="SNOMED-CT" codeSystem="2.16.840.1.113883.6.96" displayName="Condition"/> <text> . . . </text> <statusCode code="active"/> <effectiveTime> <low value="20111110"/> <high nullFlavor="UNK"/> </effectiveTime> <value xsi:type="CV" code="Z32.1" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" codeSystemVersion="10"


displayName="Encounter for pregnancy test, result positive"/> <performer typeCode="PRF"> <assignedEntity> <id root="1.3.6.1.4.1.33349.3.1.2.1.1" extension="0009" assigningAuthorityName="A Regional CHW Authority"/> </assignedEntity> </performer> </observation> </entryRelationship> </act> </entry> </section> </component> </structuredBody> </component> </ClinicalDocument>

BecauseaCDAinstancecontainsstructureddataitispossibletoextractand“disaggregate”CHWreportsifdesired(forsecondaryuse,aggregation,orifpolicyallowsdiscreterecordcreation).Furthermore,CCDscanbegeneratedfromaseriesofdiscretedatapointsintoasingleinstance(MicrosoftHealthVaultdoesthisforexportingpatientdata).

OthersimplificationtechniquesexistforthedefinitionandcreationofCDAinstancessuchastheGreenCDAproject24.GreenCDAallowsajurisdictiontodefineasimplifiedCDAschemathatis“indirectlyconformant”tothefullCDAspecification.TheGreenCDAdefinitionschema,transformsand1860documentationaredeliveredtodevelopersasassetsthatcanbeusedtocreateconformantCDAinstances.

HL7v3isamessagingframeworkthatisdesignedaroundtheRIM.UnlikeCDAwhichisav3baseddocumentformat,HL7v3messagingasamessageformat.Thedifferenceinthesetwomethodologieshasseveralramificationsforimplementation.

• CDAinstancesencapsulatethedataavailableatapointintime,aCDAdocumentcontainsthecontext,acts,observations,diagnoses,historyofpresentillness,etc..inoneinstancewhereasanHL7v3messagecontainsdiscretepiecesofdata.

• CDAisadocumentformatwhereasHL7v3isactionthatoccursastheresultofaclinicalevent(theeventmayresultinadocumentinstance)1870

• Basedonpolicydecisionsmadeaboutthelegalstatusofanelectronicmedicaldocument(i.e.:signedandattesteddocument)aCDAmaybesubjecttolegalprotection

o Inmanycountriessignedmedicaldocumentscannotbemodifiedordisaggregatedevenifitispossiblefromatechnicalstandpoint

• Documentbasedparadigmshavethepotentialofcreatingthe“listoffiles”problemwherephysiciansarepresentedwithaseriesof“snapshotintime”documentsthatcan’tnecessarilybe

24HL7International,“GreenCDAProject,”http://wiki.hl7.org/index.php?title=GreenCDA_Project.


trended.HL7v3seekstocorrectthisbyprovidingtheabilitytocontributediscretepiecesofinformation.

o Thisisnotasmuchofanissueiflegalrestrictionsrelatedtothedisaggregationofelectronicmedialdocumentsarenotspecified.1880

HL7v3messagesarenotoriousfortheircomplexityandsize,aproblemthatiscompoundedbythefactthat,untilrecently,therewasalackoftooling.AlthoughmoretoolsetsareappearingforHL7v3messaging,thenumberandqualityofthesetoolsvarywildly.

Example11illustratesasamplerequesttorecordahealthconditionofpregnancyusingtheREPC_IN000028CAmessage(REPC_IN000028UVisstillinDSTUstate).Note:ThisexampleconveysthesamedataasExample10.

Example11-RecordahealthconditionusingHL7v3

<REPC_IN000028CA ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"> . . .

<controlActEvent classCode="CACT" moodCode="EVN">

<id root="47E2DE2B-9907-47F4-B267-DEA7EAEF8207" />

<code code="REPC_TE000017CA" codeSystem="2.16.840.1.113883.1.18" />

<statusCode code="completed" /> . . . <recordTarget typeCode="RCT" contextControlCode="AP"> <patient1 classCode="PAT"> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M" assigningAuthorityName="National Health Authority" use="BUS" /> <patientPerson classCode="PSN" determinerCode="INSTANCE">

<name use="L"> <given>Mosa</given> <family>Muntabe</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1" /> <birthTime value="19920203" /> </patientPerson> </patient1> </recordTarget> <author typeCode="AUT" contextControlCode="AP"> <time value="201111101005-0500" /> <modeCode code="PHONE" codeSystem="2.16.840.1.113883.5.1064" /> <assignedEntity1 classCode="ASSIGNED"> <id root="1.3.6.1.4.1.33349.3.1.2.1.1" extension="0009" assigningAuthorityName="A Regional CHW Authority" /> <assignedPerson classCode="PSN" determinerCode="INSTANCE">

<name specializationType="PN.BASIC" use="L"> <given partType="GIV">Grace</given>


<family partType="FAM">Gillmont</family> <prefix partType="PFX">Mrs</prefix> </name> </assignedPerson> </assignedEntity1> </author> . . . <subject typeCode="SUBJ" contextControlCode="AN" contextConductionInd="true"> <conditionEvent classCode="COND" moodCode="EVN" negationInd="false"> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4" />

<statusCode code="active" />

<effectiveTime> <low value="20111110" /> <high nullFlavor="NA" /> </effectiveTime> <value code="Z32.1" codeSystem="2.16.840.1.113883.6.3" codeSystemName="ICD10" codeSystemVersion="10" displayName="Encounter for pregnancy test, result positive"/> </conditionEvent> </subject> </controlActEvent> </REPC_IN000028CA>

IHEXDS.bisn’tnecessarilyastandard,butaspecificationbasedonseveralstandardsincludingebXMLandSOAP.Itisintendedtobeusedforsharingclinicaldocumentsacrosshealthenterprises.TheIHE1890infrastructureidentifiestworolesfortheXDS.bprofile:theXDSrepositoryandtheXDSregistrywhich,whencombined,providethefunctionalityofthedocumentrepository[ROL11]describedinthisspecification.

XDS.bdoesnotdefinestructuresforclinicalcontent;ratheritactsasawrapperforclinicaldocumentcontent.DocumentsareexpressedintheXDSpayloadasbase64encodedcontentorsubmittedviaMTOM/XOP.Example12illustratesasample“ProvideAndRegisterDocumentSet-b”(ITI-41)containingtheCDAdocumentcreatedinExample10.

Example12-SampleProvideandRegisterDocumentSet-b

POST http://hix.jurisdiction.org/XDSOnRamp Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348; type="application/xop+xml"; start="0.urn:uuid:[email protected]"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b" User-Agent: Axis2 Host: localhost:5000 Transfer-Encoding: chunked --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:[email protected]>


<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:wsa="http://www.w3.org/2005/08/addressing"> <soapenv:Header> <wsa:To>http://hix.jurisdiction.org/XDSOnRamp</wsa:To> <wsa:MessageID>urn:uuid:AFBE87CB65FD88AC4B1220879854302</wsa:MessageID> <wsa:Action>urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b</wsa:Action> </soapenv:Header> <soapenv:Body> <xdsb:ProvideAndRegisterDocumentSetRequest xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:xdsb="urn:ihe:iti:xds-b:2007" xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"> <lcm:SubmitObjectsRequest> <rim:RegistryObjectList> <rim:ExtrinsicObject id="MuntabeCCD-0293" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"> . . . <rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value> 494825-231102-2022M^^^&1.3.6.1.4.1.33349.3.1.2.1.0.43&ISO </rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="sourcePatientInfo"> <rim:ValueList> <rim:Value> PID-3|494825-231102-2022M^^^&1.3.6.1.4.1.33349.3.1.2.1.0.43&ISO </rim:Value> <rim:Value>PID-5|Muntabe^Mosa^^^</rim:Value> <rim:Value>PID-7|19920203</rim:Value> <rim:Value>PID-8|F</rim:Value> </rim:ValueList> </rim:Slot> <rim:Classification id="cl01" classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="Document01"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>Grace Gillmont</rim:Value> </rim:ValueList> </rim:Slot> . . . </rim:Classification> . . . <rim:Classification id="cl07" classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="Document01" nodeRepresentation="34108-1"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>LOINC</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Summarization of episode note"/> </rim:Name> </rim:Classification> . . . </rim:ExtrinsicObject> <rim:RegistryPackage id="SubmissionSet01"> . . . </rim:RegistryPackage> <rim:Classification id="cl10" classifiedObject="SubmissionSet01"


classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/> <rim:Association id="as01" associationType="HasMember" sourceObject="SubmissionSet01" targetObject="MuntabeCCD-0293"> . . . </rim:Association> </rim:RegistryObjectList> </lcm:SubmitObjectsRequest> <xdsb:Document id="Document01"> <xop:Include href="cid:1.urn:uuid:[email protected]" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </xdsb:Document> </xdsb:ProvideAndRegisterDocumentSetRequest> </soapenv:Body> </soapenv:Envelope> --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348 Content-Type: text/xml Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:[email protected]> <ClinicalDocument xmlns="urn:hl7-org:v3"> <realmCode code="US"/> <typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/> <templateId root="2.16.840.1.113883.3.27.1776" assigningAuthorityName="CDA/R2"/> . . . </ClinicalDocument> --MIMEBoundaryurn_uuid_AFBE87CB65FD88AC4B1220879854348--

ManyopensourcereferenceimplementationsoftheXDS.bprofileareavailableandmayspeed1900adoptionanddevelopmentofbothHIXandHIXconsumers.AdditionallythereisanactivecommunityofdeveloperssupportingXDSandtheIHEprovidesexcellentdocumentationrelatedtouseoftheirprofiles25.

ItistherecommendationofthisspecificationthatjurisdictionsconsideruseofstandardsbasedXMLformatforconsumerapplicationscommunicatingwiththeHIX.EitherHL7v3orCDAareacceptablechoicesforcommunicationswiththeHIX,howeverCDAisamoreviableoptionforthefollowingreasons:

1. CDAcanbetransportedinavarietyofcontainers(XDS.b,SOAP,REST,HL7v3,HL7v2,etc…)whichplaceslessburdenonconsumerdevicesthatwillcommunicatewiththeHIX,

2. CDAcanleveragenotonlyCDAtoolingsuchasMDHTorMirthCDAPI,butHL7v3toolingsuchas1910HL7JavaSIGandEverestcanalsobeusedwithCDAwideningthetoolchain,

3. CDAinstancescanbepairedwithanXSLorotherstylesheettechnologywhichmeansthatcontentcanbedisplayedinsoftwarethatdoesn’tunderstandthesemanticmeaningofthedata,

4. CDAtemplatesandGreenCDAprovidejurisdictionswithaviableoptionforconstrainingthecomplexitiesofCDAtosuittheirneedswithoutenteringcomplexexercisesrelatedtoconstrainingRMIMsandHL7v3messagingstructures,

25IHE,“IHEWiki,”http://wiki.ihe.net/index.php?title=IT_Infrastructure.


5. CDAcancontainnon-structuredcontentaswellasstructuredcontent,providingaroadmapthatjurisdictionscanusetostructuretheirdata(startwithunstructuredinformationandmovetowardssemanticallyinteroperablestructureddata)

ThereareseveralpotentialissueswithCDA(orthedocumentparadigmingeneral)thatshouldbe1920discussedpriortoimplementation:

1. Policysurroundingthestatusofasignedmedicaldocumentshouldbeconsidered.Ifsignedmedicaldocumentsare“sealed”thereisanimpactonhowasystem,especiallytheHIX,canusethisdata,

2. Thegranularityofconsentandprivacypoliciesshouldbediscussed.i.e.:Ifonesectionofadocumentcontains“taboo”information,shouldtheentiredocumentbeblackedout,orjusttherelatedsections?

Network/PhysicalArchitectureAlthoughthisdocumentisnotintendedtobeprescriptiveaboutthedeploymentofanHIXorjurisdictionalinfrastructure,samplesofhowthearchitecturecouldbephysicallydeployedareillustrated1930inFigure53,andFigure54.

Figure53illustratesadeploymentoftheHIXintheEAIhub-and-spokepattern.Thisdeploymentofthesystemusestheon/offrampingpatternandexposesthreedifferenton-ramps:CDAoverXDS.b,CDAusingRESTfulresources,andCDAoverHL7v3.

Inthishypotheticaldeployment,thejurisdictionhasdeployedthefollowingsoftwarepackages:

Role SoftwarePackage StandardROL01-ClientRegistry CommercialEMPI PIX/PDQv3ROL03-ProviderRegistry OpenDM-MI DM-MIROL05–FacilityRegistry MARC-HIFacilitiesRegistryRI HL7v3ROL07–TerminologyRepository ApelonDTS HL7CTS1.2ROL09–SHR OpenMRS OpenMRSRESTROL23–ObservationRepository OpenMRS OpenMRSRESTROL11–DocumentRepository OpenXDS IHEXDS.b


HIX / Broker

SMS Gateway

SMSIVR SMS

Client Registry

Provider Registry

Facilities Registry

CDA over XDS.b

Terminology Service

Canonicalw/CDA Payload

Canonicalw/CDA Payload

Canonical w/CDA Payload

CTS

Lab Repository SHRDocument Repository

IHE XDS.b HL7v2 OpenMRS REST

IHE PIX/PDQ v3

DMMI

HL7v3

IVR Gateway

IVR

CDA over REST CDA over HL7v3

Figure53-SampledeploymentusingaHub-and-SpokeEAIpattern

Figure54illustratesadeploymentofaHIXusingtheEAIenterpriseservicebuspattern.Thisdeploymentusestheon/offrampingpatternandexposesthreeon-ramps:CDAoverHL7v3,CDAoverHL7v2via1940MDM^T02,andCDAoverXDS.b.

Inthishypotheticaldeployment,thejurisdictionusingthefollowingsoftwarepackages:

Role SoftwarePackage StandardROL01-ClientRegistry OpenMRS OpenMRSRESTROL03-ProviderRegistry OpenMRS OpenMRSRESTROL05–FacilityRegistry MirthMatch OMGIXSROL07–TerminologyRepository ApelonDTS XMLWrapperforDTSAPIROL09–SHR OpenMRS OpenMRSRESTROL23–ObservationRepository OpenMRS OpenMRSRESTROL11–DocumentRepository XDS.bSol’nAccel IHEXDS.b


SMS Gateway

SMS

IVR

SMS

CDA over HL7v3

CDA over XDS.b

IVR Gateway

IVR




Orchestration

Client Registry

Provider Registry

Facilities Registry

Terminology Services

Lab Repository

SHR

Document Repository

Custom XML

OpenMRS REST

OpenMRS REST

IXS


XDS.b

HL7v2

OpenMRS REST

CDA over HL7v2

Figure54-SampledeploymentusingESBpatternofEAI


Thesetwosampledeploymentsarecontrivedandhavebeenchosentoillustratethatinterfacesto/fromtheHIX,whenstandardized,canprovideconsistentaccesseventhoughtheback-endserviceschangedrastically.

TechnicalScenariosDuetotimeconstraints,therewasnotimetoprototypeworkingsoftware.Itisthegoalofthis1950specificationthatinterfacesarespecifiedtoadegreethatimplementingproofofconceptsoftwareislesscomplexandbetterunderstood.

Whilereadingthesetechnicalscenarios,thereaderisencouragedtorememberthattheHIXmerelyprovidesservices.ThesestoryboardsaresamplesofwhatcouldbepossibleifaHIXprovidingsharedservicesusinginteroperabilitystandardsispresent.

CHWVisitsPatient[SB01]Description:ACHWvisitsapregnantpatientatherhomeinaruralcommunityforaroutinevisit.TheCHWauthenticatesthembysendingaPINaChildCount+instance.TheCHWknowstheclientviapersonalrelationshipusesherbasicmobilephone(a“dumbphone”)toestablishapatientcontext.Themobiledevicegateway(ChildCount+/RapidSMS)beginsexecutionofaworkflowwhichpromptsthe1960CHWtomakeobservationsaboutthepatient;theCHWtakesthemeasurementsandsubmitsthem.Themobiledevicegatewaycollectsthedata,aggregatesitandthensubmitsthedatatotheHIXasanencountersummary[HIX01].

TheChildCount+instance’sworkflowalsodetectsthatthemeasurementsenteredbytheCHWfalloutsideoftheacceptablerangeforthepregnantclient.TheChildCount+instanceconveysthisdetectedissueeventtotheCHWviaSMSandinstructstheCHWtoasktheclientifshewouldlikevisitthereferralclinic.Theclientagreestovisittheclinic,theCHWindicatesthedecisiontothemobiledevicegatewaywhichgeneratesareferralnoteandsubmitsthereferralnotetotheHIX.

Afterseveralhoursthepatientpresentsatthelocalreferralclinic.Thepatientisaskedtoconfirmtheiridentity(viapatientcardorotherformofidentification).TheclinicianusesOpenMRStoretrievethe1970referralfromtheHIX.

TechnicalNotesTheintegrationthatisconveyedaspartofthisstoryboardrepresentswhatispossibleusinginterfacesthatareavailableanddocumentedinthecurrentversionoftheopensourcesoftwarepackagesidentifiedinthisspecification.

ItisalsoassumedthattheHIXinthisscenarioisusingtheon/off-rampingpatterndescribedintheCommunicationsArchitectureOverviewsectiononpage73.

Standards/ProfilesUsedinthisStoryboard• HL7CDA• SOAP1980• IHEXDS.b


• FREDv1.0

EdgeDevices• A“dumbphone”operatedbytheCHW• Acomputerterminaloperatedbyaclinicalatalocalreferralclinic

ConsumerActors• ChildCount+/RapidSMSmodifiedtoactasObservationRepositoryConsumer[ROL24],Referral

RepositoryConsumer[ROL22],aFederatedSecurityServicesConsumer[ROL18],andHIXMessagingConsumer[ROL14]

• OpenMRSmodifiedtoactasReferralRepositoryConsumer[ROL22],FederatedSecurityServices1990Consumer[ROL18],andHIXMessagingConsumer[ROL14]

ProviderActorsInthishypotheticalimplementation,thefollowingactorsparticipate“behindtheHIX”.NotethatHL7v3hasbeenchosenasthestandardtocommunicatewiththeHIX.

• MuleESBimplementationactingastheHIXmessagingserviceprovider[ROL13]andtheHIXorchestrationprovider[ROL27]

o Modification:Implementationoforchestrationsforhealthcaredecisionsupport• ModifiedOpenMRSactingastheObservationRepositoryServiceProvider[ROL23],Audit

RepositoryServiceConsumer[ROL16].o Modification:Authentication&SessionMechanismtosupportenterprisemessaging2000

(moreanalysisneeded)o Modification:SupportforsendingauditstoacentralAuditRepositoryo PossibleModification:Supportexplicitdefinitionoftheentity’suuid

• ADFS2.026actingastheFederatedSecurityServicesProvider[ROL17]• OpenEMPIactingastheclientregistryprovider[ROL01]andAuditRepositoryServiceConsumer

[ROL16]• AcustomizedversionofOpenDM-MIactingastheproviderregistryprovider[ROL03]• OpenXDSactingasaclinicaldocumentrepository[ROL11]• FREDreferenceimplementation[ROL05]

o NotethatFRED1.0doesnotsupportthenecessaryqueryfunctionalitytoperformthe2010requiredcross-referencingoffacility/organizationdata.Itisincludedhereasavalidationstep.

26MSDN,“UsingADFS2.0inIdentitySolutions”,http://msdn.microsoft.com/en-us/magazine/ee335705.aspx.


Figure55-TechnicalsequencediagramfromconsumerapplicationPOV

Example13


Mule : ROL13 AR : ROL15 OpenMRS : ROL23

Put Obs (HL7v3/SOAP+Token): HIX01()

Put Observation (OpenMRS REST API): SHR01()

200 OK (HTTP)

Normalize Message Structure: Normalize Message Structure

Convert Normal Form to JSON (for OpenMRS): HIX07

Additional Jurisdictional Busines Rules:

Check BRE (Business Rules):

De-Normalize Message Structure: HIX07()Acknowledge with Issues

Audit Record: AR02

A

OpenEMPI : ROL01 OpenDM-MI : ROL03

Find Alt. Identifier (PIX/MLLP): CR01()

Patient IDs (PIX/MLLP)

Find Alt Identifiers (DM-MI/SOAP): PR01()

Identifiers

Audit Disclose: AR01

OpenXDS : ROL11

Convert normal form to JSON (for OpenMRS): HIX07()

Register Document Set-b: DR01()

Acknowledge

Audit Record : AR02

FRED : ROL05

GET Facility: FR01()

200 OK

Figure56-InfrastructureoperationsforPutObservations

Example13–SampleCDAfieldreport[SHR01]2020

<?xml version="1.0" encoding="UTF-8"?> <ClinicalDocument xmlns="urn:hl7-org:v3"> . . . <id root="1.3.6.1.4.1.33349.3.1.2.2.3.2" extension="32587" assigningAuthorityName="Jurisdiction X Identifiers"/>

Example14

Example16

Example15

Example19

Example18

Example17


<code code="34133-9" displayName="Summarization of episode note" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <title>CHW Encounter 2011-11-11</title> <effectiveTime value="20111110"/> <confidentialityCode/> <languageCode code="en-CA"/> <recordTarget> <patientRole> <id root="1.3.6.1.4.1.33349.3.1.2.1.0" extension="494825-231102-2022M"/> <addr nullFlavor="NI"> </addr> <telecom value="+1 203 4958473"/> <patient> <name> <given>Mosa</given> <family>Muntabe</family> </name> <administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/> <birthTime value="19920203"/> </patient> </patientRole> </recordTarget> <author> <time value="20111110"/> <assignedAuthor> <id root="1.3.6.1.4.1.33349.3.1.2.1.1" extension="0009" assigningAuthorityName="A Regional CHW Authority"/> <telecom value="+1 209 39485675"/> <assignedPerson> <name> <given>Grace</given> <family>Gillmont</family> </name> </assignedPerson> <representedOrganization> <name>A Regional CHW Authority</name> </representedOrganization> </assignedAuthor> </author> <custodian> <assignedCustodian> <representedCustodianOrganization> <id root="1.3.6.1.4.1.33349.3.1.2.1.2" extension="109345"/> <name>ChildCount+ Gateway – Some Village</name> </representedCustodianOrganization> </assignedCustodian> </custodian> <component> <structuredBody> <component> <section> <code code="8716-3" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1" displayName="Vital signs"/> <title>Vital Signs</title> . . . <entry typeCode="DRIV"> <organizer classCode="CLUSTER" moodCode="EVN"> <id root="d11275e0-67ae-11db-bd13-0800200c9a66"/> <code code="46680005" codeSystemName="SNOMED CT" codeSystem="2.16.840.1.113883.6.96" displayName="Vital signs"/> <statusCode code="completed"/> <effectiveTime value="20111111"/> <component>

Client’sNationalHealthIDCard(root)Number(extension)

Demographicdataisincludedforvalidation(Arewetalkingaboutthesameperson?)

CHW’sLocal(ChildCount+)Identifier

Thetypeofobservationbeingmade

Demographicdataincludedtovalidatewe’retalkingaboutthesameperson.

Timetheencounter/acttookplace

Thecustodianorganization/facility


<observation classCode="OBS" moodCode="EVN"> <id root="d11275e1-67ae-11db-bd13-0800200c9a66"/> <code code="8302-2" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1" displayName="Patient Body Height"/> <text> <reference value="PtrToValueInsectionText"/> </text> <statusCode code="completed"/> <effectiveTime value="20111111"/> <value value="177" xsi:type="PQ" unit="cm"/> <interpretationCode displayName="Normal"/> </observation> </component> <component> <observation classCode="OBS" moodCode="EVN"> <id root="d11275e2-67ae-11db-bd13-0800200c9a66"/> <code code="3141-9" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1" displayName="Patient Body Weight - Measured"/> <text> <reference value="PtrToValueInsectionText"/> </text> <statusCode code="completed"/> <effectiveTime value="20111111"/> <value value="88" xsi:type="PQ" unit="kg"/> <interpretationCode displayName="Normal"/> </observation> </component> <component> <observation classCode="OBS" moodCode="EVN"> <id root="d11275e3-67ae-11db-bd13-0800200c9a66"/> <code code="8480-6" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1" displayName="Intravascular Systolic"> </code> <text> <reference value="PtrToValueInsectionText"/> </text> <statusCode code="completed"/> <effectiveTime value="20111111"/> <value value="132" xsi:type="PQ" unit="mm[Hg]"/> <interpretationCode displayName="Normal"/> </observation> </component> <component> <observation classCode="OBS" moodCode="EVN"> <id root="d11275e4-67ae-11db-bd13-0800200c9a66"/> <code code="11377-9" codeSystemName="LOINC" codeSystem="2.16.840.1.113883.6.1" displayName="Intravascular Diastolic"/> <text> <reference value="PtrToValueInsectionText"/> </text> <statusCode code="completed"/> <effectiveTime value="20111111"/> <value value="86" xsi:type="PQ" unit="mm[Hg]"/> <interpretationCode displayName="Normal"/> <referenceRange> <observationRange nullFlavor="UNK"/> </referenceRange> </observation> </component>

Firstcomponentobservation=Heightof

177cm

Secondcomponentobservation=Weightof

62.3kg

Thirdcomponentobservation=systolicBPof

132mm[Hg]

Finalcomponentobservation=diastolicBP

of86mm[Hg]


</organizer> </entry> </section> </component> </structuredBody> </component> </ClinicalDocument>

Example14–Sampleresolveclientidentifier[CR01]usingIHEPIX

MSH|^~\&|HIX_JURISDICTION|MULESOFT ESB|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20111111144546||QBP^Q23^QBP_Q21|658598754|P|2.5||||||| QPD|IHEPIXQuery|Q231235421946|494825-231102-2022M^^^NHA_PATCARD&1.3.6.1.4.1.33349.3.1.2.1.0&ISO^PI|^^^ECID&1.3.6.1.4.1.33349.3.1.2.1.3.0.43&ISO RCP|I|

Example15-Sampleauditdisclosureofinformation[AR01]usingRFC-3881

<AuditMessage> <EventIdentification EventActionCode="R" EventDateTime="2011-11-11T19:53:32.7730015-05:00" EventOutcomeIndicator="0"> <EventID codeSystemName="DCM" code="110112" displayName="Query" /> </EventIdentification> <ActiveParticipant UserIdRequestor="false" NetworkAccessPointId="CR-JURISD" NetworkAccessPointTypeCode="1"> <RoleIDCode codeSystemName="HL7 Type Code" code="RCV" /> </ActiveParticipant> <ActiveParticipant UserID="1.3.6.1.4.1.33349.3.1.2.1.0@494825-231102-2022M" UserName="(Family)Muntabe (Given)Mosa" UserIdRequestor="false"> <RoleIDCode codeSystemName="HL7 Type Code" code="RCT" /> </ActiveParticipant> <ActiveParticipant UserID="1.3.6.1.4.1.33349.3.1.2.1.1.2@1093" UserName="(Family)Gillmont (Given)Grace" UserIdRequestor="true"> <RoleIDCode codeSystemName="HL7 Type Code" code="AUT" /> </ActiveParticipant> <AuditSourceIdentification AuditEnterpriseSiteID="1.3.6.1.4.1.33349.3.1.1.20.4@CR" /> <ParticipantObjectIdentification ParticipantObjectID="1.3.6.1.4.1.33349.3.1.2.1.0@494825-231102-2022M" ParticipantObjectTypeCode="1" ParticipantObjectTypeCodeRole="1"> <ParticipantObjectIDTypeCode codeSystemName="RFC-3881" code="2" displayName="PatientNumber" /> </ParticipantObjectIdentification> <ParticipantObjectIdentification ParticipantObjectID="1.3.6.1.4.1.33349.3.1.2.1.1.2@1093" ParticipantObjectTypeCode="1" ParticipantObjectTypeCodeRole="15" ParticipantObjectDataLifeCycle="12"> <ParticipantObjectIDTypeCode codeSystemName="RFC-3881" code="11" displayName="UserIdentifier" /> </ParticipantObjectIdentification> <ParticipantObjectIdentification ParticipantObjectID="1.3.6.1.4.1.33349.3.1.2.1.0.43@B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C" ParticipantObjectTypeCode="1" ParticipantObjectTypeCodeRole="1" ParticipantObjectDataLifeCycle="11"> <ParticipantObjectIDTypeCode codeSystemName="RFC-3881" code="2"

The“external”orpublicidentifierforthepatientthatistoberesolved

Thedomainthatwewantanidentifierresolvedto

Theuser(provider)thatrequestedthepatient

demographicinformation

Thesourceoftheaudit(thesystemthatgenerated

it)

Whatwasdisclosed(Client’sECIDreferringto

thepatientrecord)


displayName="PatientNumber" /> </ParticipantObjectIdentification> </AuditMessage>

Example16-Resolveprovideridentifiers[PR01]usingDM-MISOAPAPI

<web:getEUID xmlns:web="http://webservice.index.mdm.sun.com/" xmlns:hl7="urn:hl7-org:v3"> <systemCode>1.3.6.1.4.1.21367.2010.3.2.200@MULE01</systemCode> <rootId>CF412D94-3E4D-47f7-B555-72E5C8317B14</rootId> <queryId>E2C59492-CA54-42ec-A1E2-464BA76D5E63</queryId> <providerExtension>1093</providerExtension> <providerRoot>1.3.6.1.4.1.33349.3.1.2.1.1.2</providerRoot> </web:getEUID>

Example17-Samplequeryfacility[FR01]usingFRED1.0

GET http://service.org/api/fred/v1/facilities.json?identifiers.id=109345&identifiers.agency=1.3.6.1.4.1.33349.3.1.2.1.2 HTTP/1.1 Accept: application/jsonHost: service.org{ "facilities": [ { "name": "Child Count+ Gateway - 3049", "href": "http://service.org /api/fred/v1/facilities/53adf.json", "uuid": "550e8400-e29b-41d4-a716-446655440000", "active": true, "createdAt": "2011-11-16T14:26:15Z", "updatedAt": "2011-11-16T14:26:15Z", "coordinates": [ -1.6917, 29.525 ], "identifiers": [ { "agency": "1.3.6.1.4.1.33349.3.1.2.1.2", "context": "HIM", "id": "109345" } ] } ] }

Example18-Sampleregisterdocument[DR01]usingXDS.b2030

<ProvideAndRegisterDocumentSetRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:ihe:iti:xds-b:2007" xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"> <lcm:SubmitObjectsRequest> <rim:RegistryObjectList> <rim:ExtrinsicObject id="MuntabeCCD-0293" mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"> <rim:Slot name="creationTime"> <rim:ValueList>

Thelocalidentifierthatwe’retryingtogetanenterpriseID(EPID)for

Theidentifierofthefacility(root/extensionmapto

agency/id)

EnterpriseIDforlocation.


<rim:Value>20111110</rim:Value> </rim:ValueList> </rim:Slot> . . . <rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value> B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C ^^^&1.3.6.1.4.1.33349.3.1.2.1.0.43&ISO</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="sourcePatientInfo"> <rim:ValueList> <rim:Value>PID-3| B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C ^^^&1.3.6.1.4.1.33349.3.1.2.1.0.43&ISO</rim:Value> <rim:Value>PID-5|Muntabe^Mosa^^^</rim:Value> <rim:Value>PID-7|19920203</rim:Value> <rim:Value>PID-8|F</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="CHW Encounter 2011-11-11"/> </rim:Name> <rim:Description/> <rim:Classification id="cl01" classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject="Document01"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>Grace Gillmont</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorInstitution"> <rim:ValueList> <rim:Value>Regional mHealth Gateway Data Centre</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="authorRole"> <rim:ValueList> <rim:Value>Attending</rim:Value> </rim:ValueList> </rim:Slot> </rim:Classification> . . . <rim:Classification id="cl07" classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="Document01" nodeRepresentation="34108-1"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>LOINC</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Summarization of episode note"/> </rim:Name> </rim:Classification> . . . </rim:ExtrinsicObject> <rim:RegistryPackage id="SubmissionSet01"> <rim:Slot name="submissionTime"> <rim:ValueList> <rim:Value>201111101535</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Continuity of Care Record"/>

EnterpriseIDfortheclient.

Demographicdataabouttheclient

ProviderInformationishere

Typeofdocumentbeingsubmitted


</rim:Name> <rim:Classification id="cl08" classificationScheme="urn:uuid:a7058bb9-b4e4-4307-ba5b-e3f0ab85e12d" classifiedObject="SubmissionSet01"> <rim:Slot name="authorPerson"> <rim:ValueList> <rim:Value>Grace Gillmont</rim:Value> </rim:ValueList> </rim:Slot> . . . </rim:Classification> <rim:Classification id="cl09" classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="SubmissionSet01" nodeRepresentation="History and Physical"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>LOINC</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value=" CHW Encounter 2011-11-11"/> </rim:Name> </rim:Classification> </rim:RegistryPackage> <rim:Classification id="cl10" classifiedObject="SubmissionSet01" classificationNode="urn:uuid:a54d6aa5-d40d-43f9-88c5-b4633d873bdd"/> <rim:Association id="as01" associationType="HasMember" sourceObject="SubmissionSet01" targetObject="MuntabeCCD-0293"> <rim:Slot name="SubmissionSetStatus"> <rim:ValueList> <rim:Value>Duplicate</rim:Value> </rim:ValueList> </rim:Slot> </rim:Association> </rim:RegistryObjectList> </lcm:SubmitObjectsRequest> <Document id="Document01">PD94bW......</Document> </ProvideAndRegisterDocumentSetRequest>

Example19-Createclinicalencounter[SHR11]withcreateobservations[SHR01]usingOpenMRSRESTAPI

POST http://obsencrepo.jurisdiction.org/ws/rest/v1/encounter HTTP/1.1 User-Agent: X-UA-MulesoftESB Host: obsencrepo.jurisdiction.org Content-Length: 733 { "encounterDatetime" : "2011-11-10 15:58", "patient" : "B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C", "location" : "680AF097-7F69-4AFF-808C-DDFE16463537 ", "encounterType" : "ADULTRETURN", "provider" : "622AD133-EC22-412d-A140-C052108D0481", "obs" : [ { "concept" : "5089", "value" : "62.3", "comment" : "Patient Body Weight / kg" }, { "concept" : "5090", "value" : "177", "comment" : "Patient Body Height / cm"

EnterpriseIDfortheclient.

ObservationofHeight=177cm

ObservationofWeight=62.3kg

Documentcontentthatwassubmitted

EnterpriseIDfortheprovider.

EnterpriseIDforlocation.


}, { "concept" : "5085", "value" : "132", "comment" : "Intravascular Systolic / mm[Hg]" }, { "concept" : "5086", "value" : "86", "comment" : "Intravascular Diastolic / mm[Hg]" } ] }

ObservationSystol.=132mmHg

ObservationDiastol.=86mmHg


Role&OperationReferenceRoleID OperationID ResponseID Notifications DescriptionROL01–ClientRegistryProvider CR01 CR02 AR01 ResolveClientIdentifiers CR03 CR04 AR01 PatientDemographicQuery CR05 CR06 CR07,AR02 RegisterClient CR08 CR09 CR10,AR02 UpdateClientROL03–ProviderRegistryProvider PR01 PR02 ResolveProviderIdentifiers PR03 PR04 ProviderQuery PR05 PR06 PR07,AR02 RegisterProvider PR08 PR09 PR10,AR02 UpdateProviderROL05–FacilityRegistry FR01 FR02 FacilityQuery FR03 FR04 AR02 RegisterFacility FR05 FR06 AR02 UpdateFacilityROL07–TerminologyServicesProvider TR01 TR02 ValidateCode TR03 TR04 GetCodeDetails TR05 TR06 TranslateCodeROL09–SharedHealthRecordProvider SHR21 SHR22 AR01 GetClinicalSummaryROL11–DocumentRepository DR01 DR02 AR02 StoreDocument DR03 DR04 AR01 QueryAvailableDocuments DR05 DR06 AR01 GetDocumentContentROL13–HIXMessagingServiceProvider HIX01 HIX02 SubmitMessage HIX03 HIX04 SubmitBatch HIX05 HIX06 AggregateClinicalSummary HIX07 HIX08 TransformDataStructuresROL15–AuditRepository AR01 AuditDisclosure AR02 AuditRecordCreate/UpdateROL17–FederatedSecurityServicesProvider SEC01 SEC02 AR02 AuthenticateUser SEC03 SEC04 AR01 ValidateAuthenticationToken SEC05 SEC06 AR02 UpdateUserCredentialsROL19–HealthConditionsRepositoryServiceProvider

SHR05 SHR06 AR02 RecordHealthCondition

SHR07 SHR08 AR02 UpdateHealthCondition


SHR09 SHR10 AR01 QueryHealthConditionsROL21–ReferralRepositoryServiceProvider SHR23 SHR24 AR02 RecordReferral SHR25 SHR26 AR02 FulfillReferral SHR27 SHR28 AR01 QueryReferralsROL23–ObservationsRepositoryServiceProvider

SHR01 SHR02 AR02 CreateClinicalObservation

SHR03 SHR04 AR01 QueryClinicalObservationsROL25–EncounterRepositoryServiceProvider

SHR11 SHR12 AR02 RecordClinicalEncounter

SHR13 SHR14 AR02 UpdateClinicalEncounter SHR15 SHR16 AR01 QueryClinicalEncountersROL27–HIXOrchestrationProvider HIX09 HIX10 InvokeOrchestration HIX11 ResumeOrchestrationROL28–ClientRegistryNotificationConsumer CR07 NewClientNotification CR10 UpdatedClientNotificationROL29–ProviderRegistryNotificationConsumer

PR07 NewProviderNotification

PR10 UpdateProviderNotificationROL30–CarePlanRepositoryServiceProvider SHR17 SHR18 AR02 RecordCarePlan SHR19 SHR120 AR01 QueryCarePlans


TableofFiguresFigure1-Servicerolesidentifiedforaninteroperablehealthsystem......................................................11Figure2-Resolveclientidentifier[CR01]invocationpattern...................................................................14Figure3-Patientdemographicquery[CR03]invocationpattern.............................................................14Figure4-Registerclient[CR05]invocationpattern..................................................................................15Figure5-Registerclient[CR05]sequence.................................................................................................16Figure6-Updateclient[CR08]invocationpattern....................................................................................16Figure7-Resolveprovideridentifier[PR01]invocationpattern...............................................................20Figure8-Providerquery[PR03]invocationpattern.................................................................................20Figure9-Registerprovider[PR05]invocationpattern..............................................................................21Figure10-Updateprovider[PR08]invocationpattern.............................................................................22Figure11-Facilityquery[FR01]invocationpattern..................................................................................25Figure12-Registerfacility[FR03]invocationpattern...............................................................................25Figure13-Updatefacility[FR05]invocationpattern................................................................................26Figure14-Validatecode[TR01]invocationpattern.................................................................................29Figure15-Getcodedetails[TR03]invocationpattern.............................................................................29Figure16-Translatecode[TR05]invocationpattern................................................................................29Figure17-Recordclinicalobservation[SHR01]invocationpattern..........................................................33Figure18-Queryclinicalobservation[SHR03]invocationpattern...........................................................34Figure19-Recordhealthcondition[SHR05]invocationpattern..............................................................34Figure20-Updatehealthcondition[SHR07]invocationpattern..............................................................35Figure21-Queryhealthconditions[SHR09]invocationpattern..............................................................35Figure22-Recordclinicalencounter[SHR11]invocationpattern............................................................36Figure23-Updateclinicalencounter[SHR13]invocationpattern............................................................36Figure24-Queryclinicalencounters[SHR15]invocationpattern............................................................37Figure25-Recordcareplan[SHR17]invocationpattern..........................................................................38Figure26-Querycareplan[SHR19]invocationpattern...........................................................................38Figure27-Getclinicalsummary[SHR21]invocationpattern...................................................................39Figure28-Recordreferral[SHR23]invocationpattern.............................................................................40Figure29-FulfillReferral[SHR25]invocationpattern...............................................................................40Figure30-QueryReferral[SHR27]invocationpattern.............................................................................41Figure31–Storedocument[DR01]invocationpattern............................................................................47Figure32-Queryavailabledocuments[DR03]invocationpattern...........................................................47Figure33-Getdocumentcontent[DR05]invocationpattern..................................................................48Figure34-Auditdisclosure[AR01]invocationpattern.............................................................................51Figure35-Auditrecordcreation/update[AR02]invocationpattern......................................................51Figure36-Auditsecurityevent[AR03]invocationpattern.......................................................................51Figure37-Trustednetwork.......................................................................................................................54Figure38-Brokerpatternexample...........................................................................................................56Figure39-Servicebuspatternexample....................................................................................................57


Figure40-HybridBus/BrokerPatternExample........................................................................................58Figure41-SubmitHIXmessage[HIX01]invocationpattern.....................................................................58Figure42-Sequenceofsubmitmessage[HIX01]......................................................................................59Figure43-Submitbatch[HIX03]invocationpattern.................................................................................60Figure44-Sequenceforsubmittingbatchdata[HIX03]...........................................................................61Figure45-Aggregateclinicalsummary[HIX05]invocationpattern..........................................................62Figure46-Aggregateclinicalsummary[HIX05]sequence........................................................................63Figure47-Transformdatastructure[HIX07]invocationpattern..............................................................64Figure48-Invokeorchestration[HIX09]invocationpattern.....................................................................64Figure49-SampledeploymentusingCCPandCommCaretogatherdataandsubmittoHIX..................69Figure50-Relationshipbetweendataelements(ISO12967-1,2:2007)....................................................72Figure51-On/OffRampingPattern..........................................................................................................73Figure54-SampledeploymentusingESBpatternofEAI...........................................................................97Figure55-TechnicalsequencediagramfromconsumerapplicationPOV..............................................100Figure56-InfrastructureoperationsforPutObservations.....................................................................101