Legal & Policy Advisory Group Meeting
June 25, 2013 2:30-4p

Name	Organization	
Claudia Boldman 	Information Technology Division 	
Kathleen Snyder	EOHHS Legal 	
Gillian A. Haney	MA Department of Public Health 	
Diane Stone	Stone and Heinhold Associates 	
David Szabo 	Edwards Wildman Palmer LLP 	
Laxmi Tierney (For Amanda Cassel-Kraft)	MassHealth 	
Amanda Littell-Clark	University of Massachusetts Medical School	
Sean Kennedy	MeHI	
Laurance Stuntz	MeHI	
Support Staff	Massachusetts eHealth Collaborative	
Micky Tripathi	Massachusetts eHealth Collaborative	
Mark Belanger	Massachusetts eHealth Collaborative	
Erich Schatzlein	Massachusetts eHealth Collaborative	
Jennifer Monahan	Massachusetts eHealth Collaborative	

Review of Materials and Discussion
Project Updates
•	Mass HIway Phase 2 Timeline Update (Slide 2)  
o	The group reviewed the Phase 2 timeline.  See slide for full timeline updates. Changes since our last meeting are as follows: Testing for the public health Syndromic Surveillance Node and the Children’s Behavioral Health (CBHI) Node has been completed.  Next steps are to go to production with these two and to incorporate the remaining public health interfaces.  Phase 2 release 2 timing is still October 2013-March 2014 with some Phase 2 services available as early as October.
Phase 2 Technical Design Under Consideration 
•	Key Issues Review (Slide 4) – The group reviewed the overview of the discussion material to be presented.  EOHHS and Orion have begun scoping for the technical design of Phase 2 services, and the Advisory Group was asked to provide feedback on the discussion items to follow.
•	Mass HIway Phasing (Slide 5)
o	The Mass HIway is entering Phase 2 planning and services, Search and Retrieve
•	Phase 1 and Phase 2 HIE Services (Slide 6)
o	Phase 2 service stack includes Master Person Index (MPI), consent database, Relationship Listing Service (RLS), and record retrieval services.
o	Patients are also included in the Phase 2 user types.  Over time, patients will be able to utilize some of the Mass HIway services.
•	Phase 2 Transaction Set (Slide 7)
o	Phase 2 will provide additional services offered beyond the push method used in Phase 1.  The group reviewed the list of potential transaction options made possible with the addition of the Phase 2 design (see slide for list of transactions).  The transaction list represents high-level conceptual ideas that may be possible.  
•	The RLS will assist in locating patient relationship information and will not contain any clinical information.  
•	The record retrieval service is used to request information from another provider or organization.  
•	Audit functions will provide visibility into what organizations are publishing information to the RLS and what organizations are viewing that information.
•	Update Notifications can provide subscription notifications (with consent) for providers and patients to inform them when updates are made to the RLS.  As indicated in the Provider Advisory Group, this function could be useful for keeping track of which patients follow up with referrals within Patient Centered Medical Homes (PCMH).
o	Question:  What does the term “Medical Records” apply to in this slide?
•	Answer:  The “Medical Records” term applies to the patient record information the data holding entity responds with.  Each organization will have different capabilities and preferences to how each can respond to medical record requests.
•	Consent Responsibilities (Slide 8)
o	The group reviewed the framework for consent.  Please see slide for consent responsibilities broken down by Data Holder, Data Requestor, and the Mass HIway
•	Data Holder:  Entity that has the patient record.  Consent to share is captured at the data holding entity before the possibility of sending data to the RLS or sharing record information via the HIway.  The data holder must log transactions and make data available to the patient
•	Question:  Is this the “opt-in” requirement for the HIE?
o	Answer:  Yes, this is part of the consent requirement.  The addition of consent to view/access information would satisfy the state requirement for the HIE.
o	Comment:  The original “opt-in” is also satisfied in Phase 1 consent for the provider to use the HIway.
•	Data Requestor:  Entity requesting to view/retrieve the patient record.  Consent to view/access is captured at the requesting entity before making inquiries via the HIway to view RLS information or request records.
•	Mass HIway:  Stores attestation of patient consent for publishing information to the RLS and consent for sharing information with requesting facilities.  The Data Holder still controls the decision to respond to queries and decides what information to share.
o	Question:  Can you provide an example of an “organizational relationship?”
•	Response:  If a patient has a visit with an organization, records relating to the encounter will exist, which indicates a relationship with the organization.
o	Question:  Can a patient hide the information that they visited a medical office?
•	Answer:  Yes, if a patient does not want information published, he or she would not sign a consent to share at that entity, and the information would not be made available on the RLS.
o	Comment:  An indicator should be used to notify the data requestor that the HIway does not contain all record information on a patient.  Based on patient consent preferences, the information may not be available on the HIway, but that doesn’t mean the information doesn’t exist.
•	Response:  The notification is part of participation agreements that each entity must acknowledge to participate in the HIway.
•	Comment:  A suggestion was made to make the notice more frequently expressed to providers and organizations.
•	Today: User-to-User Push (Slide 9)
o	Review of how consent works with Phase 1 services.  The HIway is used for secure email in Phase 1.  A provider can use the provider directory to locate the correct provider to send information to securely based on the certificate for the provider.
•	Framework for Query for a Patient Record - Emerging Federal Certification Approach (Slide 10)
o	The group reviewed the query and retrieve recommendations emerging from the Information Exchange Workgroup of the Federal HIT Policy Committee. The goal is to stay aligned with emerging Federal standards and the resulting stage 3 meaningful use and EHR certification requirements that may be coming from the federal HIT Standards Committee.  
•	Question:  Are other states developing query standards?
•	Answer:  Some states are working on standards, but none are robust right now.  Standards are more robust within vendor networks for cross-entity queries.  EHR vendors control the technology, so they can broker the standards and set-up models for entities to communicate.  EHR vendors do not take responsibility for the transactions.
o	There are many variations in current policies for information sharing.  Policies differ at practices, hospitals, as well at the state level in many states.  Certification occurs at the federal level, and there is no federal authority to override state and local policies.  Standards are needed to help reconcile and conform policies.
o	Ultimately, organizations should be able to query and respond to other organizations without a health information exchange (HIE) in the middle.  The HIE services will serve as an enhancement in many cases, but should not be a requirement.  
o	The group reviewed the “Send” and “Receive” requirements modeled for data requestors and data holders (see slide for requirements).
•	Note that “check for requested information” is an optional item right now because most EHRs will not have the capability to search content for specific information.
o	Minimum standards are not intended to replace greater technology requirements, and provide a lot of room to grow.  
o	Question:  Will there be a field in a record request on the HIway to indicate the preferred data format to have information sent?
•	Answer:  Indicating a preferred data format is not an option.  If this were a requirement, organizations may not participate because if unable to match the required format.  By convention, organizations may put pressure on each other and vendors to make certain data formats possible.  If organizations are unable to comply with certain data formats, referring entities may begin to push patients toward organizations with greater capabilities.
o	Question:  The Advisory Group had previously reviewed high-level use cases for the HIway.  Is the HIway still driving toward these use cases?
•	Answer:  Yes, the HIway can consider reviewing the use cases again for concept ideas while developing standards.  
o	The responsibility to fulfill or deny a request is left up to the data holder.  The data holder can choose to trust known trading partners and accept an attestation of consent, can require data requestors to send a copy of consent documentation, or can refuse practices that are not as well known to the organization.
•	For example, this is how it works today between Beth Israel Deaconess (BID) and the Security Administration (SSA). BID currently automates a query – response workflow with the SSA where BID, when queried by SSA, sends a copy of a signed patient consent along with a patient record.
o	The Privacy and Security Tiger Team has recommended that it be left up to the data holding entity to decide how to respond to a record request.  The sending organization could send a structured CCD, PDF, or other form of data.  There are no standards for the type of information to be sent.  Each organization is expected to, at a minimum, send an “acknowledgement of non-fulfillment.”
o	EHRs should have the ability to capture a single binary consent field.  This requirement does not exist now, although many EHRs can accomplish this.  There may also be an option to have an attachment to a record request that can contain a signed consent document.
•	Question:  Would the consent attachment be a digital copy, or contained in an ADT message?
•	Answer:  If incorporated, the consent document would be a digital copy of the consent form.
•	MA HIway Phase 2 Consent Approach (Slide 11)
o	The group reviewed the Phase 2 consent approach and breakdown by “Consent to Publish” and “Consent to Search or Retrieve.”
o	The RLS is to be populated by automated Health Level Seven (HL7) admission, discharge, transfer (ADT) messages sent from organizations.  An ADT message does not normally contain clinical information, but does contain demographic information about the patient and the visit.  The HIway will only store demographic info about the patient, institution name, date, and consent flag. Any other information contained in the ADT message will be immediately deleted and will not be stored by the HIway.  For Consent to Publish, the ADT message will contain a consent flag captured by the data holding entity.  If a patient does not consent to having information published, the HIway will reject the ADT message.
o	The group reviewed the patient details that would be provided in the RLS, including the ‘last visit date’ and ‘number of encounters’ listed for an institution.  Although the RLS could display a list of all encounters, the last visit date and number of encounters were considered the most helpful information without displaying a long list of items for providers to browse through.
•	The Provider Advisory Group indicated that a patient could tell providers the location of their records, which would make the RLS unnecessary in some cases.  However, other providers agreed that the RLS function is still helpful for viewing the organizational relationships for patients.
o	Question:  Does the RLS keep track of requests made by a provider or entity?  This would be helpful to identify new information available in the RLS since the last request.
•	Answer:  No, it is not likely that the RLS will be able to provide indication of new information available following a previous request.  
•	Publish Relationship to RLS (Slide 12)
o	The Consent to Publish design is based on binary flag.  If the patient provides consent, the ADT flag would say “yes” and the HIway would accept the consent and store the ADT information for publishing for others to view.
o	Chapter 224 indicates that a patient should be able to opt-in and opt-out of the HIE at any time.  The goal would be for the practice to capture a “yes” or “no” consent, and the HIway would toggle the consent flag on or off based on the most recent ADT provided.  Information on the patient would only be available from the point in time that a “yes” consent is received.  If the consent is toggled “off,” and back “on” again, the information and visit count would start over from that point in time.
•	Question:  Would the original “yes” be hidden if switching from “yes” to “no,” and back to “yes” again?
•	Answer:  If the patient switches the consent to “no,” the encounter information goes away.  If the patient changes their mind, the information will be available from the time of the new “yes” consent forward only.  The RLS is only showing if a relationship is available.  This would only be a visit count and date of last visit since consent was given.  This is stored by entity, so it only resets the count for each individual practice capturing consent.
•	Question:  If a flag for consent is not recorded or sent, does the RLS treat it as a “no?”
•	Answer:  The RLS will only accept “yes” consent flags to show information.  If a consent flag is not recorded, the RLS will treat the consent indication as “no.”
•	View RLS Information (Slide 13) and Provider record retrieval options (Slide 14)
o	The group briefly reviewed the slide details; please refer to slide for full information.
•	Provider Subscription to Changes in Patient RLS (Slide 15)
o	Provider subscriptions models are emerging now.  Providers could subscribe to certain patients’ RLS information, and receive notification as information changes.  The providers could then go view the changed information.  Configuration of what type of information change would prompt subscription notifications would be needed to ensure the notifications are relevant and useful.
o	Consent for subscription would need to be captured separately somewhere in the HIway.  Some remaining questions are:  How would the HIway determine the subscription consent?  How would a provider and the HIway maintain current subscription consent information, especially if patient leaves a practice?  How would a patient or provider cancel a subscription?
o	Question:  Will the consent for to allow providers to subscribe be patient driven?
•	Answer:  This may be an option in the future, but the HIway doesn’t have the ability to incorporate for patients right now.
•	Patient Options (Slide 16)
o	The largest question currently, is how to provide patient access to the HIway.  There are ways to validate organizations and providers right now through Board of Registration in Medicine (BORIM), but no current validation process for patients.  If the patient has a Personal Health Record (PHR) account, how can a provider validate the PHR account for patient identity before sending information?  One potential option would be for the HIway to provide a Direct address for patients in the same way it is done for providers.
o	Adding patient accessibility to the HIway could give patients the ability to view RLS information and receive records from providers.  Patients may also benefit from the possibility of subscribing to notifications for changes in the RLS for their information.
o	Question:  Patient Centered Medical Home (PCMH) and other programs are driving to have patients “owned” by a provider.  Would it be an option to have the provider delegate credentials to the patient?
•	Response:  The question may involve determining if providers are willing to do this.  Providers will be directly involved in setting up patients for their own patient portals for MU2 requirements, so it may be unlikely that provider would want to take on credential responsibilities for the HIway as well.
o	Suggestion:  Amend slide 6:  “Consent Database” to show that the flag is stored by the HIway but the consent is actually maintained by the provider offices.
•	Question:  Patients may have difficulty keeping track of consent authorizations they have given at multiple organizations.  Has the option of having RLS return a record of consents for the patient to view by mail or email been discussed?
o	Answer:  Yes, this may be possible for patients to view consent records via the RLS when patients are added to the HIway.

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 Advisory Group Meeting – July 16, 2:30-4:00 pm.  
o	MMS Plymouth Conference Room, Or conference call – number to be updated in invitation
•	HIT Council – July 1, 2013, 3:30-5:00 One Ashburton Place, 21st Floor

•	Question:  When is information updated on the EOHHS website?
o	Answer:  Meeting materials and minutes are uploaded to the EOHHS website.  The minutes go through an Advisory Group review process before being posted, so there is a slight delay following the meeting before the information is posted.
•	Question:  Next version of participation agreement – Will the HIway be looking for input from the Advisory Group for areas to address in the next version of the participation agreement for Phase 2?
o	Answer:  Yes, and this will be coordinated within EOHHS in the future, but the EOHHS not ready to begin drafting the agreement yet.
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