hisp

HISP-to-HISP Discussion
May13,2013
HISP Definition
What is a HISP?An organization that provides security and transport services for directed exchange based on the DirectprotocolThe term HISP does not have any authoritative meaning outside of the directed exchange protocol described in theApplicability Statement for Secure Health Transport (July 2012)2014 Certification Standards cover EHRs, not HISPsWhat does a HISP do?AssuranceProvide assurance of identity of participant (entities and individuals) and justification for participation in the trust communityIssue and maintain Direct email addresses to participants (entities and individuals)SecurityAssociate each email address with at least one security certificate and assure Direct-compliant payload encryption as specified by each addresseeMaintain akeystoreof public keys discoverable to other HISPs through industry-standard protocols (e.g., DNS, LDAP, other)StandardsProcess Direct-compliant messages to and from assigned addressees using SMTP/SMIME (and optionally, XDR/SOAP), signed and encrypted using X509 certificates
Breakdown in the HISP model
A key goal of the Direct Projectwas tohavefederated, scalable trustwherebyeachHISP maintainsa trustfabric through contractswithinthe HISP,but requires no further trust fabric formalitiesbetweenHISPs:Core HISP functions should be well-understood and transparentInter-HISPtrust not needed due to end-to-end encryptionApplies only to directed exchange functions – not defined for other functions such as queryRelies on end-users’ trust across HISPs (i.e., end-users in one HISP accept trust established to end-users in other HISPs)Services integration (provider directory, certificate exchange,etc) does not require complex business and technical agreementsYet, in reality, we have encountered a number of operational issues that weren’t fully recognized at the time that Direct wasspecifiedThere is no statutory or regulatory oversight of HISPs – standards apply to EHRs, NOT to HISPsWidevariety of models claiming to beHISPs – non-compliance withDirect specifications as well asallowable variations within the Direct-project specificationInconsistent trust fabric requirements – wide variety of within-HISP trust models that at a minimum require diligence before enabling cross-HISP exchangeScope of HISP activities –some HISPsperform more functions than just directed exchange, such as query-basedtransactionsTechnical integration – provider directory integration is not standardized, requiring detailed and ad hoc integrationapproaches
The original HIway HISP concept
[email protected]
trustintegration
HISP
[email protected]
trustintegration
trustintegration
Massachusetts providers connecting directly through their EHRs
Other Regional and State HISPsNational-level HISPs (eg,Healtheway)
Need for HISP-to-HISP policies
Original HISP concept envisioned HISPs as facilitators that would not require any type of HISP-to-HISP contracts“thereshould be no need for HISPs to require contractual relationships as a precondition for exchange using Direct Project compliantimplementations”In practice, HISP-to-HISP contracts are proliferatingThe proliferation of HISP models wouldn’t be as big an issue EXCEPT for the fact that many Massachusetts providers may only be able to connect to the HIway via HISP-HISP arrangementsSome will be forced to by their EHR vendors (eg,eCW, Cerner)Others may choose to through local HIEs and nationwide networks (eg,Surescripts)This adds policy, contract, and technical complexity to the HIway modelTrust/assuranceapproachRevenuemodelService model(e.g., provider directory robustness and completeness,uniform Direct address domains,etc)
Need to define policy and technical approaches to variety of HISP models that exist in the market
HIway trustHIway integration
HIway trustHIway integration
HISP
HISP trustHISP integration
HISP-HISP trustHISP-HISP integration
Vendor Integrators
HIway Participants
Non-HIway HISP participants
HIwayHISPParticipants
HIway integration
Many types of organizations that HIway needs to consider
Key areas to address in policy, contract, and technical requirements