collaborative health platform - colleaga · part of the system. this logical architecture is...
TRANSCRIPT
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
CollaborativeHealthPlatformSpecification 3
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.
CollaborativeHealthPlatformSpecification 5
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
CollaborativeHealthPlatformSpecification 6
• 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
CollaborativeHealthPlatformSpecification 7
• 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
CollaborativeHealthPlatformSpecification 8
• 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.
CollaborativeHealthPlatformSpecification 9
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,
CollaborativeHealthPlatformSpecification 10
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.
CollaborativeHealthPlatformSpecification 11
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
CollaborativeHealthPlatformSpecification 12
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.
CollaborativeHealthPlatformSpecification 13
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.
CollaborativeHealthPlatformSpecification 14
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]
Client Registry Service Provider
[ROL01]
Client Registry Service Consumer
[ROL02]
Demographic Query[CR03]
Demographic Resp. [CR04]
Audit Repository[ROL15]
Audit Disclosure [AR01]
310
Figure3-Patientdemographicquery[CR03]invocationpattern
Thedemographicquery[CR03]operationmustbecapableofsearchingthelistofpatientsavailablebasedonthename,genderandageoftheclient(atminimum).Theresultofthissearch[CR04]willbealistofpatientdemographicrecordsofthosepatientsthatmatchthesuppliedparameters.
CollaborativeHealthPlatformSpecification 15
RegisterClient[CR05]
Client Registry Service Provider
[ROL01]
Client Registry Service Consumer
[ROL02]
Register Client [CR05]
Acknowledgement [CR06]
Client Registry Notification Consumer[ROL28]
Submit Notification [HIX01]
Audit Repository[ROL15]
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.
CollaborativeHealthPlatformSpecification 16
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]
Client Registry Service Provider
[ROL01]
Client Registry Service Consumer
[ROL02]
Update Client [CR08]
Acknowledgement [CR09]
Audit Repository[ROL15]
Audit Record [AR02]
Client Registry Notification Consumer[ROL28]
Submit Notification [HIX01]
HIX[ROL13] Client Update Notif. [CR10]
Figure6-Updateclient[CR08]invocationpattern
Theupdatenewclientoperation[CR08]providesthefunctionalityofupdatinganexistingclientrecord.Anupdatemaybeademographicupdatetoclientinformation,ormaybeamerge/unmerge(i.e.:MosahasjustbeenregisteredintheHIVregistry,herIDforthisregistryis567).Theclientregistryshouldgenerateanotification[CR10]thatclientinformationhasbeenupdated,andshouldsubmitthistothe340
CollaborativeHealthPlatformSpecification 17
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.
CollaborativeHealthPlatformSpecification 18
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.
CollaborativeHealthPlatformSpecification 19
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.
CollaborativeHealthPlatformSpecification 20
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]
Provider RegistryService Supplier
[ROL03]
Provider Registry Service Consumer
[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.
CollaborativeHealthPlatformSpecification 21
RegisterProvider[PR05]
Provider RegistryService Supplier
[ROL03]
Provider Registry Service Consumer
[ROL04]
Register Provider[PR05]
Acknowledgement [PR06]
HIX[ROL13]
Submit Notification [HIX01]
Audit Repository[ROL15]
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.
CollaborativeHealthPlatformSpecification 22
UpdateProvider[PR08]
Provider RegistryService Supplier
[ROL03]
Provider Registry Service Consumer
[ROL04]
Update Provider [PR08]
Acknowledgement [PR09]
HIX[ROL13]
Submit Notification [HIX01]
Audit Repository[ROL15]
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
CollaborativeHealthPlatformSpecification 23
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].
CollaborativeHealthPlatformSpecification 24
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.
CollaborativeHealthPlatformSpecification 25
• 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]
Facility Registry Service Supplier
[ROL05]
Facility Registry Service Consumer
[ROL06]
Register Facility [FR03]
Acknowledgement [FR04]
Audit Repository[ROL15]
Audit Record [AR02]
Figure12-Registerfacility[FR03]invocationpattern
Thefacilityregistrationoperation[FR03]permitstheregistrationofanewfacilitywithinthefacilityregistry.Theresultoftheoperationisanacknowledgement[FR04]indicatingwhethertheregistrationofthefacilitywassuccessful.
Itisassumedthattheregistrationofservicedeliverylocationswillbeperformedbyacentralauthorityresponsibleforthemaintenanceoffacilitieswithinajurisdiction.Forthisreason,thebroadcastingoffacilityregistrationisnotrequired.
CollaborativeHealthPlatformSpecification 26
UpdateFacility[FR05]570
Facility Registry Service Supplier
[ROL05]
Facility Registry Service Consumer
[ROL06]
Update Facility [FR05]
Acknowledgement [FR06]
Audit Repository[ROL15]
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.
CollaborativeHealthPlatformSpecification 27
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,
CollaborativeHealthPlatformSpecification 28
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.
CollaborativeHealthPlatformSpecification 29
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]
Terminology Services Provider[ROL07]
Terminology Services Consumer[ROL08]
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]
Terminology Services Provider[ROL07]
Terminology Services Consumer[ROL08]
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)
CollaborativeHealthPlatformSpecification 30
• 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”.
CollaborativeHealthPlatformSpecification 31
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.
CollaborativeHealthPlatformSpecification 32
• 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.
CollaborativeHealthPlatformSpecification 33
RecordClinicalObservation[SHR01]
Observation Repository Service
Provider[ROL23]
Observation Repository Service
Consumer[ROL24]
Record Obs. [SHR01]
Acknowledgement [SHR02]
Audit Repository[ROL15]
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].
CollaborativeHealthPlatformSpecification 34
QueryClinicalObservation[SHR03]
Observation Repository Service
Provider[ROL23]
Observation Repository Service
Consumer[ROL24]
Query Obs. [SHR03]
Obs. List [SHR04]
Audit Repository[ROL15]
Audit Disclosure [AR01]
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]
Health Conditions Repository Service
Consumer[ROL20]
Record HC [SHR05]
Acknowledgement [SHR06]
Audit Repository[ROL15]
Audit Record [AR02]
Figure19-Recordhealthcondition[SHR05]invocationpattern
Therecordhealthconditionoperation[SHR05]registersanewhealthconditionwiththehealthconditionrepository.Informationrelatedtothehealthconditiontype,time,anddiagnosingprovider810shouldbeexpectedbytheoperation.Theresultofthisoperationisanacknowledgementindicatingwhethertheregistrationofthehealthconditionwassuccessful.
CollaborativeHealthPlatformSpecification 35
UpdateHealthCondition[SHR07]
Health Conditions Repository Service
Provider[ROL19]
Health Conditions Repository Service
Consumer[ROL20]
Update HC [SHR07]
Acknowledgement [SHR08]
Audit Repository[ROL15]
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]
Health Conditions Repository Service
Provider[ROL19]
Health Conditions Repository Service
Consumer[ROL20]
Query HC [SHR09]
HC List [SHR10]
Audit Repository[ROL15]
Audit Disclosure [AR01]
Figure21-Queryhealthconditions[SHR09]invocationpattern
Thequeryhealthconditionsoperation[SHR09]willquerytheavailablehealthconditionsforaparticularclientbasedonconditiontype,status,andseverityatminimum.Theresultofthequeryisalistofallhealthconditionsthatmatchthespecifiedquerycriteria.
Thedisclosureofthehealthconditiontothecallerwillresultinanaudit[AR01]ofthedisclosureevent.
CollaborativeHealthPlatformSpecification 36
RecordClinicalEncounter[SHR11]830
Encounter Repository Service Provider
[ROL25]
Encounter Repository Service Consumer
[ROL26]
Record Enc. [SHR11]
Acknowledgement [SHR12]
Audit Repository[ROL15]
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]
Encounter Repository Service Provider
[ROL25]
Encounter Repository Service Consumer
[ROL26]
Update Enc. [SHR13]
Acknowledgement [SHR14]
Audit Repository[ROL15]
Audit Record [AR02]
840
Figure23-Updateclinicalencounter[SHR13]invocationpattern
CollaborativeHealthPlatformSpecification 37
Theupdateclinicalencounter[SHR13]operationcreatesanewversionoftheclinicalencounterwithintheencounterrepository[ROL25].Theupdateclinicalencounteroperationwillallowcallerstoupdateinformationabouttheencounter,ortoassociatenewclinicaldatawiththeencounter.Theresultoftheupdateoperationisanacknowledgement[SHR14]whichconveyswhetherornottheupdateoperationwassuccessful.
QueryClinicalEncounters[SHR15]
Encounter Repository Service Provider
[ROL25]
Encounter Repository Service Consumer
[ROL26]
Query Enc. [SHR15]
Enc. List [SHR16]
Audit Repository[ROL15]
Audit Disclosure [AR01]
Figure24-Queryclinicalencounters[SHR15]invocationpattern
Thequeryclinicalencounters[SHR15]operationwillsearchtheencounterrepository[ROL25]forclinical850encountersthematchthespecifiedcriteria.Atminimum,thesearchoperationshouldpermitfilteringbasedonencountertype,starttime,andstatus.Theresultofthequeryoperationisalist[SHR16]ofallencountersthatmatchthespecifiedcriteria.
AswithalldisclosureofPHI,thequeryclinicalencounteroperation[SHR15]willresultinanauditofdisclosure[AR01]
CollaborativeHealthPlatformSpecification 38
RecordCarePlan[SHR17]
Care Plan Repository
Service Provider
[ROL30]
Care Plan Repository
Service Consumer
[ROL31]
Register CP [SHR17]
Acknowledgement [SHR18]
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]
Audit Repository[ROL15]
Audit Disclosure [AR01]
Figure26-Querycareplan[SHR19]invocationpattern
CollaborativeHealthPlatformSpecification 39
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]
Audit Repository[ROL15]
Audit Disclosure [AR01]
Health Conditions Repository Service
Provider[ROL19]
Referral Repository Service Provider
[ROL21]
Observations Repository Service
Provider[ROL23]
Encounter Repository Service Provider
[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
CollaborativeHealthPlatformSpecification 40
RecordReferral[SHR23]
Referral Repository Service Provider
[ROL21]
Referral Repository Service Consumer
[ROL22]
Record Ref. [SHR23]
Acknowledgement [SHR24]
Audit Repository[ROL15]
Audit Record [AR02]
Figure28-Recordreferral[SHR23]invocationpattern
Therecordreferraloperation[SHR23]isresponsiblefortheregistrationofnewreferralsinthereferralrepository[ROL21].Dataelementsrelatedtothereferralincludestatus,targetprovider/facility,reasonandnote.Theresultoftherecordoperationisanacknowledgement[SHR24]thatindicateswhethertherecordofthereferraldatawassuccessful.
FulfillReferral[SHR25]
Referral Repository Service Provider
[ROL21]
Referral Repository Service Consumer
[ROL22]
Fulfill Ref. [SHR25]
Acknowledgement [SHR26]
Audit Repository[ROL15]
Audit Record [AR02]
Figure29-FulfillReferral[SHR25]invocationpattern890
Thereferralfulfillmentoperation[SHR25]isaspecializedupdateoperationthatmarksthereferralasfulfilledandlinksthereferraltotheencounterthatfulfillsthereferral.Theresultofthisoperationisanacknowledgement[SHR26]whichindicateswhetherthefulfillmentofthereferralrecordwassuccessful.
CollaborativeHealthPlatformSpecification 41
QueryReferral[SHR27]
Referral Repository Service Provider
[ROL21]
Referral Repository Service Consumer
[ROL22]
Query Ref. [SHR27]
Ref. List [SHR28]
Audit Repository[ROL15]
Audit Disclosure [AR01]
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.
CollaborativeHealthPlatformSpecification 42
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.
CollaborativeHealthPlatformSpecification 43
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
CollaborativeHealthPlatformSpecification 44
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
CollaborativeHealthPlatformSpecification 45
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.
CollaborativeHealthPlatformSpecification 46
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.
CollaborativeHealthPlatformSpecification 47
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]
Audit Repository Service Provider
[ROL15]
Document Repository Service Provider
[ROL11]
Audit Disclosure [AR01]
Document Repository Service Consumer
[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.
CollaborativeHealthPlatformSpecification 48
Aswithalldisclosureofdata,thequeryresultsinanaudit[AR01]ofdisclosureofinformation.
GetDocumentContent[DR05]
Audit Repository Service Provider
[ROL15]
Document Repository Service Provider
[ROL11]
Audit Disclosure [AR01]
Document Repository Service Consumer
[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.
CollaborativeHealthPlatformSpecification 49
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.
CollaborativeHealthPlatformSpecification 50
• 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.
CollaborativeHealthPlatformSpecification 51
• AuditRepositoryServiceProvider[ROL15]–AsystemimplementingtheauditrepositoryserviceprovidemustbecapableofacceptingauditsforthecreationanddisclosureofPHI.
• AuditRepositoryServiceConsumer[ROL16]–Asystemimplementingtheauditrepository1130serviceconsumeriscapableofsendingauditstoafederatedauditrepository.
IdentifiedOperationsThefollowingoperationshavebeenidentifiedfortheauditrepository.EachoftheoperationsidentifiedhasauniqueidentifierstartingwithARwhichisusedtounambiguouslyidentifytheoperation.
AuditDisclosure[AR01]
Audit Repository Service Provider
[ROL15]
Audit Repository Service Consumer
[ROL16]Audit Disclosure [AR01]
Figure34-Auditdisclosure[AR01]invocationpattern
Theauditdisclosureoperation[AR01]isanasynchronouscallfromtheauditrepositoryserviceconsumer[ROL16]totherepositoryprovider[ROL15]whichseekstorecordauditinformationrelatedtothedisclosureofinformation.1140
AuditRecordCreation/Update[AR02]
Audit Repository Service Provider
[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]
Audit Repository Service Provider
[ROL15]
Federated Security Service Provider
[ROL17]Audit Security Evt. [AR03]
Figure36-Auditsecurityevent[AR03]invocationpattern
CollaborativeHealthPlatformSpecification 52
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.
CollaborativeHealthPlatformSpecification 53
• 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)
CollaborativeHealthPlatformSpecification 54
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.
CollaborativeHealthPlatformSpecification 55
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.
CollaborativeHealthPlatformSpecification 56
HIX Provider[ROL13 & ROL27]
HIX & OBS Consumer
[ROL14 & ROL24]
Record Obs [SHR01]
Client Registry Service Provider
[ROL01]
Resolve Identifiers [CR01]
Provider Registry Service Provider
[ROL03]
Resolve Identifiers [PR01]
Observations Repository Service
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.
CollaborativeHealthPlatformSpecification 57
HIX & OBS Consumer
[ROL14 & ROL24]
Record Obs [SHR01]
Client Registry Service Provider
[ROL01]
Provider Registry Service Provider
[ROL03]
Acknowledgement [SHR02]
Resolve Identifiers [CR01] via HIX
Resolve Identifiers [PR01] via HIX
HIX Messaging Service Provider
[ROL13]
Observations Repository Service
Provider[ROL23]
Record Obs [SHR01]
Acknowledgement [SHR02]
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.
CollaborativeHealthPlatformSpecification 58
HIX & OBS Consumer
[ROL14 & ROL24]
Record Obs [SHR01]
Client Registry Service Provider
[ROL01]
Provider Registry Service Provider
[ROL03]
Acknowledgement [SHR02]
Observations Repository Service
Provider[ROL23]
Record Obs [SHR01]
Acknowledgement [SHR02]
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]
HIX Messaging Service Provider
[ROL13]
HIX Messaging Service Consumer
[ROL14]
Submit Msg [HIX01]
Msg. Result [HIX02]
Clinical Repository / Registry[ROLXX]
Invoke
Response
HIX Orchestration Provider[ROL27]
Invoke Orch. [HIX09]
Figure41-SubmitHIXmessage[HIX01]invocationpattern
CollaborativeHealthPlatformSpecification 59
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]
CollaborativeHealthPlatformSpecification 60
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.
CollaborativeHealthPlatformSpecification 61
HIX Messaging : ROL13HIX Consumer : ROL14
Submit Batch: HIX03()
Repo 1HIX Orch. : ROL27
Invoke Orch: HIX09()
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.
CollaborativeHealthPlatformSpecification 62
ItisrecommendedthattheHIXorchestrationprovider[ROL27]beusedtoorchestratethedisaggregationofthebatchandcoordinationofcalls.Additionally,compensationlogicshouldbeincludedintheHIXorchestrationprovider[ROL27]tocleananyremnantsofpartialdata.1350
AggregateClinicalSummary[HIX05]
HIX Messaging Service Consumer
[ROL14]
Get Summary [HIX05]
Aggregate Results [HIX06]
HIX Orchestration Provider[ROL27]
Invoke Orch. [HIX09]
Clinical Repository / Registry 2[ROL09]
Clinical Repository / Registry 3[ROL09]
Clinical Repository / Registry 1[ROL09]
Get Summary [SHR21]
Get Summary[SHR21]
Get Summary[SHR21]
HIX Messaging Service Provider
[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.
CollaborativeHealthPlatformSpecification 63
HIX Messaging : ROL13HIX Consumer : ROL14
Aggregate Clinical Summary: HIX05()
Repo 1 : ROL09HIX Orch. : ROL27
Invoke Orch: HIX09()
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
CollaborativeHealthPlatformSpecification 64
TransformDataStructures[HIX07]
HIX Messaging Service Provider
[ROL13]
HIX Messaging Service Provider
[ROL13]
Transform Data [HIX07]
Terminology Services Provider[ROL07]
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]
HIX Messaging Service Provider
[ROL13]
HIX Orchestration Provider[ROL27]
Invoke Orch. [HIX09]
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.
CollaborativeHealthPlatformSpecification 65
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/)
CollaborativeHealthPlatformSpecification 66
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.
CollaborativeHealthPlatformSpecification 67
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:
CollaborativeHealthPlatformSpecification 68
• 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.
CollaborativeHealthPlatformSpecification 69
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
CollaborativeHealthPlatformSpecification 70
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].
CollaborativeHealthPlatformSpecification 71
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
CollaborativeHealthPlatformSpecification 72
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
CollaborativeHealthPlatformSpecification 73
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
CollaborativeHealthPlatformSpecification 74
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,
CollaborativeHealthPlatformSpecification 75
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"
CollaborativeHealthPlatformSpecification 76
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.
CollaborativeHealthPlatformSpecification 77
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.
CollaborativeHealthPlatformSpecification 78
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.
CollaborativeHealthPlatformSpecification 79
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^A04 PRPA_IN201301UV02 PRPA_IN101201CA RegisterEntityWithIdentityCR07 ADT^A31 PRPA_IN201301UV02 PRPA_IN101001CA CR08 ADT^A04 PRPA_IN201302UV02 PRPA_IN101204CA UpdateEntityTraitValuesCR10 ADT^A31 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
CollaborativeHealthPlatformSpecification 80
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|^^^ECID&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|^^^ECID&1.3.6.1.4.1.33349.3.1.2.1.3.0.43&ISO PID|||B38F9ECA-B3D3-4d32-8E06-8D10CC0AC07C^^^ECID&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 ^^^ECID&1.3.6.1.4.1.33349.3.1.2.1.43&ISO^PI ||MUNTABE^MOSA||19920203|F|||^^Local Village^SA^7321
CollaborativeHealthPlatformSpecification 81
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
CollaborativeHealthPlatformSpecification 82
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>
CollaborativeHealthPlatformSpecification 83
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.
CollaborativeHealthPlatformSpecification 84
<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> . . .
CollaborativeHealthPlatformSpecification 85
</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.
CollaborativeHealthPlatformSpecification 86
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
CollaborativeHealthPlatformSpecification 87
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
CollaborativeHealthPlatformSpecification 88
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/.
CollaborativeHealthPlatformSpecification 89
<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"
CollaborativeHealthPlatformSpecification 90
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.
CollaborativeHealthPlatformSpecification 91
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>
CollaborativeHealthPlatformSpecification 92
<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]>
CollaborativeHealthPlatformSpecification 93
<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"
CollaborativeHealthPlatformSpecification 94
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.
CollaborativeHealthPlatformSpecification 95
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
CollaborativeHealthPlatformSpecification 96
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
CollaborativeHealthPlatformSpecification 97
SMS Gateway
SMS
IVR
SMS
CDA over HL7v3
CDA over XDS.b
IVR Gateway
IVR
Canonical w/CDA Payload
Canonical w/CDA Payload
Canonical w/CDA Payload
Orchestration
Client Registry
Provider Registry
Facilities Registry
Terminology Services
Lab Repository
SHR
Document Repository
Custom XML
OpenMRS REST
OpenMRS REST
IXS
Canonical w/CDA Payload
XDS.b
HL7v2
OpenMRS REST
CDA over HL7v2
Figure54-SampledeploymentusingESBpatternofEAI
CollaborativeHealthPlatformSpecification 98
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
CollaborativeHealthPlatformSpecification 99
• 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.
CollaborativeHealthPlatformSpecification 100
Figure55-TechnicalsequencediagramfromconsumerapplicationPOV
Example13
CollaborativeHealthPlatformSpecification 101
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
CollaborativeHealthPlatformSpecification 102
<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
CollaborativeHealthPlatformSpecification 103
<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]
CollaborativeHealthPlatformSpecification 104
</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)
CollaborativeHealthPlatformSpecification 105
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.
CollaborativeHealthPlatformSpecification 106
<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
CollaborativeHealthPlatformSpecification 107
</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.
CollaborativeHealthPlatformSpecification 108
}, { "concept" : "5085", "value" : "132", "comment" : "Intravascular Systolic / mm[Hg]" }, { "concept" : "5086", "value" : "86", "comment" : "Intravascular Diastolic / mm[Hg]" } ] }
ObservationSystol.=132mmHg
ObservationDiastol.=86mmHg
CollaborativeHealthPlatformSpecification 109
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
CollaborativeHealthPlatformSpecification 110
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
CollaborativeHealthPlatformSpecification 111
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
CollaborativeHealthPlatformSpecification 112
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