Technology Advisory Group

May Meeting

 	May 24, 2013
Agenda

Project Update
HISP-to-HISP Exchange
Phase 1 Consent
Next Steps

Phase 2 overall timeline
Current Status
 	There are a number of organizations technically connected to the HIway, and production transactions are starting to grow
•	One million+ cumulative transactions have been transacted over the HIway production system
•	In May alone the HIway has transacted:
-	500K+ discharge/ED summaries and HL7 labs from Tufts Medical Center to Network Health
-	40K+ CCDs from BIDMC to MAeHC Quality Data Center
-	400+ HL7s from BIDMC to DPH Immunization Registry (stage)

 	MeHI Implementation Grant Program should accelerate demand for HIway services

MeHI Grants Will Generate Demand for HIway Services
Agenda

Project Update
HISP-to-HISP Exchange
Phase 1 Consent
Next Steps
HISP Definition
 	What is a HISP?
•	An organization that provides security and transport services for directed exchange based on the Direct protocol
•	The term HISP does not have any authoritative meaning outside of the directed exchange protocol described in the Applicability Statement for Secure Health Transport (July 2012)
•	2014 Certification Standards cover EHRs, not HISPs

 	What does a HISP do?
•	Assurance
-	Provide assurance of identity of participant (entities and individuals) and justification for participation in the trust community
-	Issue and maintain Direct email addresses to participants (entities and individuals)
•	Security
-	Associate each email address with at least one security certificate and assure Direct-compliant payload encryption as specified by each addressee
-	Maintain a keystore of public keys discoverable to other HISPs through industry-standard protocols (e.g., DNS, LDAP, other)
•	Standards
-	Process 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 Project was to have federated, scalable trust whereby each HISP maintains a trust fabric through contracts within the HISP, but requires no further trust fabric formalities between HISPs:
•	Core HISP functions should be well-understood and transparent
•	Inter-HISP trust not needed due to end-to-end encryption
•	Applies only to directed exchange functions – not defined for other functions such as query
•	Relies 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 agreements

 	Yet, in reality, we have encountered a number of operational issues that weren’t fully recognized at the time that Direct was specified
•	There is no statutory or regulatory oversight of HISPs – standards apply to EHRs, NOT to HISPs
•	Wide variety of models claiming to be HISPs – non-compliance with Direct specifications as well as allowable variations within the Direct-project specification
•	Inconsistent trust fabric requirements – wide variety of within-HISP trust models that at a minimum require diligence before enabling cross-HISP exchange
•	Scope of HISP activities – some HISPs perform more functions than just directed exchange, such as query-based transactions
•	Technical integration – provider directory integration is not standardized, requiring detailed and ad hoc integration approaches
The original HIway HISP concept
Need for HISP-to-HISP policies
Original HISP concept envisioned HISPs as facilitators that would not require any type of HISP-to-HISP contracts
•	“there should be no need for HISPs to require contractual relationships as a precondition for exchange using Direct Project compliant implementations”
•	In practice, HISP-to-HISP contracts are proliferating

The 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 arrangements
•	Some 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 model
•	Trust/assurance approach
•	Revenue model
•	Service 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
Many types of organizations that HIway needs to consider
Key areas to address in policy, contract, and technical requirements
Is Direct Trust the answer?
 	Trust community that agrees upon common technical, business, and legal standards
•	Formed to head off proliferation of one-off bilateral contracts among HISPs

 	62 members as of May 2013
•	Of relevance to HIway:  eCW, Cerner, Surescripts, RIQI, Orion, Symantec

 	Three elements:
•	Framework with consensus policies – currently X509 Certificate Policy and Federation Agreement
•	Accreditation through EHNAC (First 4 vendors just certified including Cerner and Surescripts)
•	Trust Anchor Bundle Distribution Service 
-	Collection of trust anchors (root certificates) that meet common set of minimum policy requirements within a Trust Community Profile
-	Trust community profile – policies and requirements on selected organizations getting together for specific use cases

 	Direct Trust is not (yet) a magic bullet
•	Still have relatively limited membership
•	Only 8 trust anchors from 5 organizations included at present – relevant to HIway:  Cerner, Surescripts, RIQI
•	Robustness and consistency of policies still being developed
What Direct Trust does not answer
 	Variations in eligibility and participation requirements
•	They have a model trust agreement, but participants seem to be customizing it according to local policies and desires

 	Implicitly assumes complete end-user trust across HISPs
•	We would still have to define policy/technical approaches for segregating MA providers from others, if that becomes our policy

 	Relatively few trust bundles defined at present
•	But that should grow rapidly over time

 	Many policy and technical issues still not ready for prime time
•	Requirement that HIway work within Direct Trust governance and working group structure to bring the model to industry readiness
Other considerations
We don’t want to make a mountain out of a molehill
•	Need to remember that this is just for Phase 1 directed exchange right now -- basically secure email functionality
•	Too much uncertainty in the market to try to address Phase 2 (query) issues now

Standardized RA/CA processes to enforce mutual trust around bundles of certificates have not yet been defined and are hard to define given dynamic nature of the market

Security approach for SMIME/XDR transformation still needs to be worked out, but there are a number of viable options under consideration now

Given the nascent state of the market, each HISP and Integrator implementation is still unique and will likely remain so for some time to come
•	We expect to see some convergence in scaleable approaches, but the market is not there yet
Agenda

Project Update
HISP-to-HISP Exchange
Phase 1 Consent
Next Steps
Consent for Phase 1 Services
 	Chapter 224 requires that patient has ability to “opt-in” and “opt-out” of HIE, however:
•	Language was not updated from Chapter 305 (passed in 2008) to reflect new HIE architecture and better industry understanding of HIE and consent
•	In particular, HIway Phase 1 is basically secure email – highly circumscribed activity with no patient data repositories or query capabilities
•	Opt-in not defined
•	“Opt-out” is not defined in the way that the industry defines it

 	Most large organizations and many small ones already opt-in patients for information-sharing
•	Usually incorporated in “consent to treat” – sometimes bound with consent for treatment, sometimes separated
•	Does not distinguish mode of communication – authorizes sharing regardless of mode

 	A proposed operational approach for Phase 1 consent would be:
•	Opt-in should include an actual consent for information-sharing that specifically names the MA HIway as a mode of exchange
-	Not just an NPP; shouldn’t remain silent on MA HIway
•	An example that would cover this and is aligned with many current consent workflows:
-	Consent to treat that includes information-sharing with other providers
-	Update to NPP to list MA HIway as a mode of exchange
•	EOHHS is in process of evaluating this definition
Agenda

Project Update
HISP-to-HISP Exchange
Phase 1 Consent
Next Steps
Next steps
 	Next steps
•	Key points and comments synthesized and provided back to Advisory Group for final comments
•	Presentation materials and notes to be posted to EOHHS website
•	Next Technology Advisory Group Meeting – June 21, 2013, 2-3:30pm.  Conference line only:  (866) 792-5314, Code: 7814347906#
•	Next HIT Council – June 3, 2013, 3:30-5:00 One Ashburton Place, 21st Floor

 	HIT Council meeting schedule, presentations, and minutes may be found at http://www.mass.gov/eohhs/gov/commissions-and-initiatives/masshiway/hit-council-meetings.html