Technology Advisory Group Meeting
June 28, 2013 2-3:30p

Name	Organization	
Atia Amin	Network Health	
Karen Bell	CCHIT	
Claudia Boldman	Information Technology Division	
Chris Diguette	Atrius Health	
Larry Garber	Reliant Medical Group	
Keith Worthley	BIDMC	
Matthew Moss	South Shore Hospital	
Adrian Gropper		
Jon Merantza		
Ian Rowe	Orion Health	
David Bowditch	EOHHS	
Support Staff	Massachusetts eHealth Collaborative	
Micky Tripathi	Massachusetts eHealth Collaborative	
Dave Delano	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	Orion Health and the Massachusetts Executive Office of Health and Human Services (EOHHS) have been deeply engaged in requirement sessions for the scoping of phase 2.  Advisory Group feedback is being solicited.  
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.
o	To date, over 1.3 million Phase 1 transactions have been transmitted through the Mass HIway. Activity is starting to accelerate with the help of the IMPACT Grant Program in Western MA and the Massachusetts eHealth Institute (MeHI) HIway Implementation Grants (part of the Last Mile Program). Thirty two grantees/organizations were awarded funding, all of whom will connect to the HIway. 

Phase 2 Preliminary Functional Design
•	Today’s Session (Slide 4) – The meeting will focus the current high-level approach to Phase 2 and the results of the scoping sessions that have been happening over the last several weeks. 
•	Phase 1 Functions: User-to-User Push (Slide 5) - Phase 1 current capabilities were reviewed: Diagram showing the user-to-user push workflow. 
•	Framework for Query for a Patient Record - Current Direction of Federal Certification Approach for MU Stage 3 (Slide 6) - 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.  . 
o	 Currently there are no national standards for query; the HIway will orient the phase 2 approach to leverage where the national standards are headed.
o	The slide material provides a framework for what the requirements for a query standard might look like, based on the current direction of Federal Certification Approach for MU Stage 3. The current framework shows a query and response set of transactions with the minimum set of information required to sufficiently support the transaction; direction from the standards committee favors a “RESTful” (REST - Representational State Transfer) web service approach at this time. 
o	The workflow diagram addresses what transport and payload information would be required to create a successful transaction: 
-	It must handle authentication, which will be supported by the HIway if entity is connected
-	It needs some representation of patient identifying information to unambiguously match patients 
-	It requires some type of authorization for request so the data holding entity can evaluate and decide if they feel comfortable responding to the request with medical information. 

•	Question: Is the “authorization for request” wording on the slide another word for consent? 
•	Answer: Yes, for some types of information you may not need formalized consent, but a representation that you are authorized. One example: In states where HIPAA is the binding constraint, you would not need any other authorization.

•	The current recommendation says that “assurance” (Privacy and Security Tiger Team term) of the authorization, patient matching criteria, and what to respond with, should be locally made by the data holding entity. 
o	The data holding entity can decide  whether or not they are satisfied with the information received in the request and respond in whatever way they can. Those standards need to be flexible due to variations in the market at this time. 
•	Comment: It was mentioned that this is the same concept as the Regional Extension Centers (REC’s); the data holder makes the final decision which allowed for flexible/federated authentication using OpenID Connect. It has yet to be seen whether data holders will have an opportunity to both authenticate themselves or through some other intermediary. 
•	Comment: It is helpful that the model does not require the state to have a Master Patient Index (MPI); in other words we could do this today, it is something that has a low threshold for entry into actually setting this up. 
•	MA HIway Phase 2 Consent Approach - Patient consent on both sides of transaction (Slide 7) - In Phase 2, the state will be creating a Relationship Listing Service (RLS), which is a facilitating service to provide a listing of the relationships a patient has with provider organizations.  It is not required for query, but a value that the HIway will provide to help a querying organization know where to target a record request. 
o	Phase 2 Consent Approach has consent on both sides of a disclosure: one to publish the relationship to the RLS and one for the data requestor who views the RLS. Patient consent to publish information to the RLS will be captured in automated Health Level Seven (HL7) admission, discharge, transfer (ADT) messages sent from organizations. Organizations would work with the HIway to integrate ADT feeds.  The data holder would be responsible for maintaining the consent documentation.  
o	On the other side, if you want to query, view and go retrieve patient information, , the patient would give consent to the data requester to view the RLS; this consent will be conveyed in the query message. The query should contain a place to document a consent preference. The Legal and Policy Advisory Group can help work through policy recommendation for which ones of these are actual formal consent and which are strong implied consent. 
•	Question: Would implied consent take care of the scenario of an unconscious patient in the Emergency Room? 
•	Answer: Yes, there is implied consent for a medical emergency. The provider is making the attestation that there is implied consent because the patient is having a medical emergency.  
•	Question: Who can view the published information? Do you need to be federated within the HIE? Can any provider on the HIway look at any patient or patient relationship on the RLS?  
•	Answer: Today providers sign a contract saying they will only access a record for treatment purposes; essentially on the honor system. There is a need for something more structured. The current concept says that the viewing entity must have an established relationship; in other words it has contributed ADT information to the RLS. If there is no established relationship, the provider cannot access the record. If someone comes in for a first visit, and there is no established relationship, the information will not be viewable.  
•	Comment: Worth noting that one organization would most likely be on both sides of the equation and gather both sides of the consent; publish to the RLS and to search and retrieve. 
o	Response: That could be how it gets operationalized. 
•	Question: Which ADTs are we talking about; that the patient has registered or that they have actually had a visit?
•	Response: Ian Rowe will explain this in the technical design portion of the presentation. 
•	The Data Holder Publishes Patient/Entity Relationship to RLS (Slide 8) – The RLS will contain date last message received, number of visits/episodes and facility. The slide provides further detail on the population of the RLS with the assumption that most EHR’s can capture only a single binary consent flag in their ATD message. 
o	Consent flags will be relayed in the ADT message. Multiple ADT’s might be sent during the same visit, the stream of ADT messages will get collapsed at the RLS instead of publishing each individually. 
o	Once ADT messages are flowing, for a particular entity sending a string of messages, the consent flag acts like a memory-less toggle, an on/off switch, that allows or prohibits the relationship to be published in the RLS. 
o	If the HIway receives an ADT message, maybe for the first time on a particular patient, and the ADT says “no,” it will be rejected. If it is a “yes,” the relationship gets published.
o	The RLS will be populated with the date of the last ADT message and roughly how many episodes the patient has had at each location. Not a perfect mapping; a particular episode could generate 10-12 ADT messages. Orion will continue to work on this. 
o	If the patient changes from “yes” to “no” then back to “yes” the RLS will start from scratch. Previous messages will no longer be there. 
•	 Question: What if there are multiple ADT messages, some “yes” and some “no” coming from a single hospital admission as the patient moves through different departments within an organization and a new ADT message is triggered each time? 
•	Answer: Consent is collected at registration. Once they move to radiology for example, they will not be triggered to give consent again for the same event. 
•	Comment: Orion is working through this; one potential solution is to use registration as the authoritative consent. 
•	Question: If someone said yes, then after a period of time they switched to no, then they went back to yes. The implication is that when they query that organization, the organization that had “no” for awhile, will need to keep track and know not to release information for that period of time when the consent was “no.” Are you saying that the holder of the record needs to keep track of what can be sent during the period of “no” consent.
•	Answer: The record holding entity is going to respond with what they want to respond with. What needs to be communicated to the patient, by flipping consent, it is not segmenting what information is available when someone makes a query.  The consent given is only for publishing information to the RLS, not indicating what information can be shared. 
•	Question: When someone goes from Yes to No, you effectively erase their history. I can understand not increasing the counts, but when they go back to saying Yes, wouldn’t it be valuable to continue counting from where the ADTs were left off. That way you can see that there is an ongoing message
•	Answer:  The HIway is keeping the history (for audit), but hiding it. The design team went back and forth with this, but these are the kinds of issues that the various policy committees need to determine. On the Orion end it is just a configuration in technology.
•	Question: With respect to the consent; is the assumption that the accounting for disclosure, the changes from “yes” to “no” back to “yes” is being maintained by the information holder? 
•	Answer: Yes, the RLS would also know but the information is hidden. Originally, the idea was to reject all “no’s,” but if a patient started with a “yes,” then went to “no,” the HIway cannot reject the switch for audit purposes. The RLS will maintain a record of these “flips,” while the entities involved in the query and response would be accountable for the disclosure piece.
•	Question: Would a patient need to chase around to however many entities are listed if they actually wanted to know what was going on with their disclosure preferences? 
•	Answer: Yes, the RLS only knows what it knows; the on/off information. You could have query and responses, where you have the flexibility to have the patient not consent to a relationship being posted on the RLS but still give consent for a request for the patient’s medical record. 

•	The Data Requestor Requests Patient Record – Data Holder Responds (Slide 9) – The slide shows the workflows between the data requester and the data holder as described previously. 
o	An organization has the ability to view relationships with consent to search/retrieve information.  The information available to view is constrained by the relationships known to the RLS.  The RLS can be used as facilitating tool to identify relationship and target a query request.  If you eliminate the RLS from the equation, an organization can still complete point-to-point query
o	There is a single bit (consent flag) for the search and retrieve, which is not the same bit as the consent to publish. Consent to view and consent to publish are the same, query is separate.
o	A consent form can represent to the holder that they have consent to publish, and have consent to see the records or give them to someone else. From the point of view of the system, they are really two separate things. Some organizations may want to implement a consent form that assures the relationship for both bilateral operations, but from a system point of view it is actually four different bits. 
•	Question: EHRs are likely to only store one bit, and so, are we sending that same bit?
•	Answer: The thought is that if you looked at a system today, most are able to capture one bit and populate an ADT. The assumption is that a query standard, which is yet to be defined, would require the capability to capture a consent to query. 
•	Comment: If we assume there will be changes, potentially to store all four bits. A patient may like to have one single place to consent, rather than consent at for every single disclosure type. 
•	Response: You could have a single form within your organization that covers all bases, but if any patient opts out of any one of those events you are stuck because you cannot compartmentalize. 
•	Comment: It is up to the record holder to determine how it handles the information and how many bits it uses. What Orion is doing, in order for the RLS to work, is setting the requirement to one bit. 
•	Comment: The fact that all of this depends on a perfect, or unique match, in the MPI, means that this stateless system, which is opaque to that patient by design, could be very difficult to operationalize on a large scale. With distributed responsibilities on storing consent/authorization information, any mismatches in the MPI will create interesting problems. 
•	Patient possible patient options (Slide 10)
o	The biggest business issue will be the on-boarding and management of the patient accounts. Each patient will have an address that has been validated, a provider could also send information directly to the patient via this address. (Example: Jennifer.Jones@hv.masshiway.net)
o	Patients can view an audit log, receive notification of RLS changes, and manage their consent. The issue to tackle is the synchronization of that information with the HIway and the EHR sitting in the provider’s office. 

Phase 2 Preliminary Technical Design:  Presented by Ian Rowe, Orion Health 
•	Starting at the top left of the diagram on slide 12, there are a number of information sources to feed the relationships. Orion started with the premise that messages would be primarily ADT, there are others that need to be supported such as Patient Demographics Query (XPDQ) or other forms. 
•	Some organizations will orchestrate their ADT and “pre clean” their information. The “data filter” will remove everything but the Patient Identification (PID) segment to accommodate differing ADT formats. Strip out all of the unwanted segments. The basic information needed from the ADT:
o	Surname
o	Given name
o	Gender
o	Date of Birth
o	Address
o	Consent Assertion
•	Comment: In the future, mobile phone number might also be helpful for matching. 
•	Response: Right now the focus is on the PID segment, the rest of the segments will be discarded. They are discarded in a way that they do not keep an audit of those inbound messaging. The audit log will be time stamped with a message ID, but will not attest to what the message contained. HIway can attest that they received the information. 
•	A few records will have a confirmed “match,” or a confirmed “no match” so that a new patient ID is created.  There will also be a number of near matches; an organization will need to review and resolve the match manually. For the period the identity is unresolved, the relationship does not get added to the main database, it will sit in a separate store until resolved.
•	 There is a lot of debate about what date to publish. Given the number of ADT’s, various types and the historical encounter data, the date the relationship was established has been used; still working to create logic around this. 
•	The relationship listing is trying to show “how thick is this file,” in order for the provider to imply something about the relationship with the facility. When a request comes in to view the relationship, the HIway will return a single relationship based on the rollup of multiple ADT messages and the date of the event. Get a feeling of the relevance of the other relationships; whether you use the record retrieval, fax or pick up the phone to request the record. 
o	Question: Is Orion saving the first and last date of contact? 
•	Answer: Currently all of the relationship records are being saved, but does not to show the first visit date. It includes the from address, number of contacts, and the date of the last event. The team is still discussing the value of including the first date. 
o	Comment: The date of registration would also be helpful if included, the provider would know the first and last date of contact. Including the organization type would also be helpful; inpatient, outpatient or ER designations.  
•	Response: Orion is saving the relationships, the from address and number of contacts. 
o	Question: about the relationship list, how the responses will come back with providers that have prior relationships. Would that be kept at the Direct address level?
•	Answer: The granularity is defined by the record holder.
o	Question: where does the direct address come in?
•	Answer: The message is received from a Direct address, the EHRs are using the Direct standards to send the ADT payload. The consumer portal will allow the patients to have Direct addresses. 
o	Comment: It was suggested that the direct address be assigned at the time of registration, when consent/authentication is collected. 
•	Food for Orion thought: If we are able to get the Direct address from the provider organization ADT, how would we leverage that? 
o	Question: How will the HIway handle the merged and unmerged events?
•	Answer: Some will be valid, and the HIway will process those. Orion plans to sit down and work through this issue. Utilizing the MRN will be vital, Orion plans to walk through each particular transaction to work through any nuances. 
•	Pilot sites will be solicited to take inventory on each transaction scenario. Orion plans to wrap up the documentation on the first set of requirements and then present the information to a group of stakeholders to get into some of the potential pitfalls missed in the original design. 

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 19, 2:00-3:30 pm.
o	Conference call – number to be updated in invitation
•	HIT Council – July 1, 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