Healthcare Information Exchange (HIE)

Handling Security in a Centralized HIE

CEO of Maine Exchange Describes Strategy
Handling Security in a Centralized HIE

As those developing health information exchanges weigh various data architecture models, the CEO of Maine's HealthInfoNet argues that its model, which relies on a central data repository, offers the best security.

Devore Culver contends the main alternative to a central repository model - the federated model in which data reside within each provider organization and is queried as needed - is far less secure because there is less centralized control.

See Also: Live Webinar | Embracing Digital Risk Protection: Take Your Threat Intelligence to the Next Level

"Security is only as good as the weakest point in the provider organizations that are participating [in a federated model]," he says in an interview with HealthcareInfoSecurity's Marianne Kolbasuk McGee (transcript below).

By using a centralized model, he argues, security measures are more easily standardized.

"In a central repository model, we're able to institute important perimeter and penetration management tools," he notes. Plus, the encrypted repository keeps patient clinical data separate from patient ID information to enhance security. "To hack through that, you'd have to hack through both encrypted data sets," he says.

Nevertheless, Maine's statewide HIE takes extra steps to ensure security, Culver explains. For example, HealthInfoNet hires a third party to attempt to break into the system twice a year. "We don't know when that's coming," he says. "We have no idea how they're going to attack us, what their various methods are going to be. That's a very important step in maintaining the credibility around the central data repository model."

Culver says the level of privacy and security in an HIE needs to be above the general community practice in healthcare, "because we're doing things that make people uncomfortable and therefore you need to be able to speak to a slightly higher standard or practice."

Also in the interview, Culver explains:

  • Why the exchange is using cloud computing for its new service offering access to stored medical images;
  • How the HIE handles patient consent issues, using an opt-out approach for most data, but an opt-in approach for AIDS/HIV and mental health information;
  • How auditing data helps its member healthcare providers' chief information security officers identify suspicious patterns of data access;
  • Why HealthInfoNet pays a third party to attack its systems twice a year; CUT THIS
  • How the HIE plans to provide consumers access to their health data.

Before joining HealthInfoNet in 2006, Culver served as CIO at Eastern Maine Healthcare, a seven-hospital integrated delivery network. He also formerly held senior management positions at Eclipsys Corp. and Cerner, two healthcare software companies. He has served on Maine's State Information Systems Advisory Board and was co-chair of the Governor's Task Force on Telemedicine.

HealthInfoNet

MARIANNE KOLBASUK MCGEE: Could you tell us a little bit about your organization and your role?

DEV CULVER: HealthInfoNet is a Maine not-for-profit organization. It was formed in January of 2006. It's a stakeholder organization in that its community board of directors includes representatives from the consumer community, provider community, payer community, business and state government. And to that end, that board of 19 has been instrumental in helping to position the organization for its primary mission today ... supporting coordination of care and helping to begin to look at ways to improve safety, reduce cost and hopefully create a better outcome for patients who are being served by it.

Today, the exchange has 25 of Maine's 39 hospitals connected and exchanging data bi-directionally. We also have an additional nine hospitals under contract. That means they're in the process of connecting right now. That leaves essentially three hospitals that are still not under contract. High anticipation is that all hospitals in Maine will be under contract and fully connected by the end of 2013.

Additionally, we're also connecting physicians and practices, and we have just over 200 practices connected today for bi-directional exchange and 1,000 primary care physicians under contract for connection through the regional extension center grant program out of the Office of the National Coordinator [for Health Information Technology]. Today, we have approximately 1 million lives with some data in the system. ... That's about 78 percent of all the residents in the state of Maine.

Central Data Repository Model

MCGEE: Tell us a little bit about the data architecture model that you use to exchange data.

CULVER: We use a central data repository model. ... Back in 2005, the provider community that came together to define this operation made two very fundamental decisions. One was they agreed that they wanted to have their clinical data integrated into a single data set. And the second was that they agreed to stop competing on patient data. Both of those are fundamental to building the initial trust model that's in place today. The decision to go with the central data repository model had perhaps more to do with some understandings about the advantages of having an integrated data set than specifically about security, although I think that we've accomplished some things in the umbrella of security that probably reinforced why it was a good decision. ...

Primarily, from some other experiences in Maine involving an all-payer claims database and a few other statewide efforts, it was clear that we were going to get some additional advantages out of being able to standardize the data set and being able to start using the clinical data to help support not only just the transition of information from one point to another, but also, quite frankly, the ability to start looking at things like clinical rules and real-time alert structures. Having it as a centralized data repository was critical [in] being able to accomplish those objectives. We also have a mission specific to serving public health and, quite frankly, [that's a] very challenging objective if you can't standardize data. ... That was a fundamental part of the original design.

From a security perspective, I think the reason we felt - and the consumer groups around us felt - that the central repository model was a reasonable strategy was that in building the architecture, we have been able to physically separate the clinical data itself from the personal identifier data, so they actually live in two separate data structures. Then, both of those data structures are encrypted at rest and they're only brought back together on demand - and demand, in this case, means a user accessing the portal to [access patient information].

For someone to hack that structure is a fairly significant challenge. Not only would you have to hack through the encryption on both of the data sets, but then you would also have to figure out how to put back together the web service calls to make the actual data come together so it was identifiable.

I think we've entertained a reasonable strategy. One of the reasons, beyond all the ones that I mentioned, [was] that we felt the central data repository model was perhaps a bit safer than the alternative, which is a federated model where the data lives at home with the individual providers and then gets called based on a record locator structure. In the federated model, your security is only as good as the weakest point in the provider organizations that are participating, as far as going out and finding data. Whereas in the central data repository model, you're able to institute some important perimeter and penetration management tools that further improve the probability somebody isn't going to hack you. I think those are the core reasons, from a security perspective, why we have gone down the architecture we've gone down.

Security Precautions

MCGEE: Are there any special precautions that you needed to take because you have a centralized model, versus if you would have gone with any of the other models, federated or hybrid?

CULVER: I think that not only do you pay attention to your perimeter and to your penetration questions, but actually try to have a fairly consistent schedule of attempting to break the system. For example, we pay a third party to attack us twice a year. We don't know when that's coming. We have no idea how they're going to attack us, what their various methods are going to be. And that's a very important additional step I believe in maintaining the credibility around the central data repository model. You would probably want to do that even if you were working inside of a federated model, but I think it becomes more important only because the concept of the data being centralized ... is perceived to be more at risk. I don't believe that to be the case by the way, but I do think you do have to take some extra precautions, in including things like fairly regular penetration testing.

Protecting Image-Related Data

MCGEE: HealthInfoNet is also one of the first health information exchanges in the country to enable medical image sharing. Are there any extra steps you needed to take or any other technologies that you needed to implement to protect image-related data?

CULVER: It's interesting because I don't think the data itself defines the strategies. The data's just one more element. I think the strategy for what we're doing in the image repository adds some additional challenges. This is a statewide image repository. It will serve primarily as the archive structure, but it also will serve as the point of reference for providers who are looking to have access to important prior testing.

And to that end, the architecture's different than the exchange. It's, in fact, going to be based on a cloud architecture. Inherent in the cloud architecture are some additional demands for security around the protection and identification of source and use. ... Quite frankly, the opportunities that we are taking on right now as a proof of concept for the next six months ... before we move forward into a full-fledged utilization will be to validate the additional security that our vendor - in this case it's Dell - will bring to the table to sustain a level of viability in a cloud-based architecture. Again, we're not [using] a cloud-based architecture at the exchange ourselves, but we will now introduce that into the structure for the support of images. And it's really the only reasonable way, quite frankly, to develop an image repository of the size and scope we're talking about.

Obtaining Patient Consent

MCGEE: Can you describe your approach in obtaining patient consent for exchanging information?

CULVER: Our consent model in Maine is an opt-out consent model. That was established through an interesting process with a consumer advisory structure, which is actually a codified part of our bylaws. In our bylaws, we have two standing committees to the board. One is a consumer advisory committee. That committee is constituted by people who represent both advocacy functions, like the American Civil Liberties Union and Planned Parenthood, and also folks who are there just because they're consumers.

In 2007 and 2008, we spent an extended period debating opt-in/opt-out and quite frankly what we were doing [was] really based on treatment - the question of whether you needed to have patient involvement at all because the exchange and what's functioning and how it's contracted to the providers really is working under HIPAA. ... There was a debate even [on whether] you need to have the consumer state a preference. ...

After a great deal of discussion, we agreed on an opt-out strategy. Interestingly, the opt-out strategy in 2007 came with a hook, and that's the Civil Liberties Union was very unhappy about an opt-out but agreed to have it go into a demonstration project with one important understanding - and that was HealthInfoNet would remove the clinical data from the exchange in its entirety if a person chose to opt-out. So basically, what we agreed to [was that] if we at least would take the data out so it's no longer part of the data set - the clinical data - then they would be willing to go forward and have the exchange demonstrate itself.

I think that was a wise move, and in essence it allowed the exchange to move forward. We had some educational requirements in terms of how to get consumers to understand what was going on, and basically addressed that problem which all exchanges have - and that's, if it's an opt-in model, how do you get someone to take action? How do you get them to declare themselves one way or another? That's really the foundation.

Now we've made it a little more complex. [In] the legislative cycle ending in June of 2011, the legislature decided to change a state law involving HIV test data and data generated by licensed mental health providers. Prior to that, the consent laws were such that the patient had to give written consent and specifically identify who the information was being leased to in order ... to provide content, which obviously ruled out using an exchange. So now, [as a result of the new state law,] the licensed providers for mental health and folks generating HIV results can release that information. It's not everything. It's a defined data set, but they can release that information to the exchange. The exchange must take the data in and sequester it and not make it available or visible until such time as the patient specifically opts-in for allowing that content to be viewed. So now we've got an opt-out for general medical information and an opt-in for mental health and HIV test results. We're working on this right now to stand it up. [It's] a little more confusing and a little more challenging, technically, but I think it's a compromise that's fair.

MCGEE: It allows some granular consent right?

CULVER: Exactly. ... We were actually increasingly hearing from ... both the mental health community and the HIV community. They were feeling discriminated against because they had members who wanted their information in but, because of the law, they couldn't include it.

Authenticating Users

MCGEE: What approach are you taking when it comes to authenticating the identity of organizations or individuals that are using the exchange?

CULVER: The way our exchange is defined, interestingly enough, HealthInfoNet does not take ownership of the data. The responsibility of the ownerships continues to reside with the originating provider and with that then comes the responsibility for who they authorize and what role they declare for those accessing the exchange.

There's a formal process for every organization, whether it's a practice or a hospital, which goes under contract with the exchange, where an individual is the source authorizing specific people by role. And we have [defined] seven roles. And each role defines a slightly different view of what you can see. That's a formal process where a written authorization comes forward to the exchange from that organization. We go ahead and identify that person against the identified role and provide the credentials on a temporary basis for them to become part of the structure and sign in and establish their permanent credentials within the sector.

What that means though, and this is really the important part, is that every organization that's under contract is going at risk with the other organizations in terms of the behavior of their employees. Now that's a very powerful structure. It's been an interesting experience getting security officers comfortable with that concept, but in the end, because the security officers have complete access to all of the auditing data inside the exchange, they can very quickly look at usage based on either a patient or any user in the exchange and make that an extension of their own internal auditing strategies. We've gained quite a bit of comfort with the concept that people are able to identify behaviors and find patterns that will reinforce behaviors that are positive.

We do run an active audit program within the exchange. Just recently, since I'm the security officer, too, for the organization, I identified some patterns of behavior with a physician user that ... involved her looking at her mother's medical record on a repeated basis and quite frankly [it] turned out that she was sanctioned for her behaviors. While she had the right intent, she really was not the physician of record caring for her mother. So that's the kind of thing which we pay a great deal of attention to. But at the end of the day, because everybody's responsible for the people they've authorized to be in, it takes the control and management structure right back into the organization that's providing the authorization to access.

Best Practices for Data Security, Privacy

MCGEE: What advice would you give to any start-up health information exchanges out there in terms of best practices for data security and privacy when planning their strategies?

CULVER: I think there are some core things to consider. ... There's really not enough energy and time placed in those first early steps in terms of starting to build the trust model. And I mean that both in terms of the provider communities that are engaged as well as the consumer community. Spend the time to work through and get to consensus ... on how the exchange will operate and what the rules of engagement are. ...

For example, one of the things we haven't talked about is in the early planning phases, the consumer group brought forward its "if we could have everything, this is what we want" list, and clearly one of the key things that we still have not delivered on but are trying to get to this year is providing direct access by the consumer to their information in the exchange. That's a fundamental building block - getting that trust network to work. In addition, ... we provide any consumer who wishes the ability to call for an audit of who has been in their record in the exchange - and that's both good in terms of building trust but also it's a wonderful enforcement standard for keeping people doing the right things as users. That would be a fundamental building block.

The second thing is to step back and take a look at what you're trying to do with the data. In our case, the vision was larger than just moving it from point A to point B. And so with that comes some additional requirements to stop and think a little bit about your security structures. You need to stop and develop a fairly robust set of policies around how you manage it, how you access it, how you authorize and audit what gets done. Those things need to be basically well laid out and ... vetted regardless of whether you're [using] a central data repository model or a federated model.

The real key beyond that is exchanges need to live at a level of privacy and security performance that's above the general community practice in healthcare. Because, either in perception or fact, we're doing things that make people uncomfortable and therefore you need to be able to speak to a slightly higher standard or practice. That's why we've chosen the architecture we've chosen, because it permits us to be able to both encrypt data in motion and encrypt data at rest, which I think is a fundamental expectation of any organization, exchange or provider. [It] quite frankly has to be a core standard of practice for a true standing as an exchange. You really do need to be able to speak to that expectation of encryption both at rest and in motion for the data sets. And again, that's an evolving area, and, quite frankly, challenging because the price for being encrypted at rest is that it slows down the process and you [have] to work to balance those two because I do think exchanges need to be living in a standard that's slightly above the community standard.


About the Author

Jeffrey Roman

Jeffrey Roman

News Writer, ISMG

Roman is the former News Writer for Information Security Media Group. Having worked for multiple publications at The College of New Jersey, including the College's newspaper "The Signal" and alumni magazine, Roman has experience in journalism, copy editing and communications.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing healthcareinfosecurity.com, you agree to our use of cookies.