Legal/Policy Advisory Group

May Meeting

 	May 28, 2013
Agenda

Project Update
Phase 1 Consent
HISP-to-HISP Exchange
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
Phase 1 Consent
HISP-to-HISP Exchange
Next Steps
Consent for Phase 1 Services
 	Despite the fact that Phase 1 services are essentially “a step up from faxing”, there is some confusion in the market about consent requirements for the HIway

 	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) and thus does not reflect new HIE architecture and more mature industry understanding of HIE and consent
•	HIway Phase 1 is basically secure email – highly circumscribed activity with no patient data repositories or query capabilities
•	Law does not define key terms
-	“Opt-in” not defined at all
-	Implied definition of “opt-out” is not consistent with standard industry definition

Implementing Phase 1 Consent
 	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
•	Often 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 a notice such as 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 and options for providing greater clarity to the market

 	Leveraging current “consent to treat” and NPP to also cover HIway opt-in would likely work for most larger entities but many small practices do not have formal “consent to treat”
•	Some small practices may have to begin a more formalized consenting process to accompany their NPPs
•	EOHHS in process of evaluating ability to provide examples to assist process
Key Questions on Phase 1 Consent
 	What issues and concerns do you have regarding the Phase 1 consent process?

 	What additional guidance or facilitation can EOHHS provide to assist with this process?

Agenda

Project Update
Phase 1 Consent
HISP-to-HISP Exchange
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 a 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
•	Received ONC grant to further work in security and trust “rules of the road”

 	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

What Direct Trust does not answer
 	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

 	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
Key Questions on HISP-to-HISP Policies
 	Are there organization/contracting variants that were not identified?

 	Given that Phase 1 service is essentially secure email, what are the main trust issues that need to be addressed?
•	Eligibility criteria and uses?
•	Alignment of polices and procedures?
•	Access to provider directory?
•	Other?
Agenda

Project Update
Phase 1 Consent
HISP-to-HISP Exchange
Next Steps
Next steps
 	Next steps
•	Key points and recommendations synthesized and provided back to Advisory Group for final comments
•	Presentation materials and notes to be posted to EOHHS website
•	Next Legal & Policy Advisory Group Meeting – June 18, 2013, 2:30-4pm.
-	MMS Plymouth Conference Room
-	Conference line:  (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