An HIE Leverages Best Practices

Building on Members' Security Experience
An HIE Leverages Best Practices

Those who are implementing new health information exchanges should look for ways to leverage the best security practices of participating organizations, advises Chris Carmody, who heads a well-established HIE in Western Pennsylvania.

See Also: Confronting the New Economics of Cybersecurity with Risk Automation

"You don't have to reinvent the wheel," Carmody says in an interview with HealthcareInfoSecurity's Marianne Kolbasuk McGee (transcript below). "Look back to how you've accomplished implementing electronic health record systems and other IT systems in a healthcare setting and try to leverage those best practices ... that are in place today, and how that could be applied to your health information exchange."

Nine organizations in western Pennsylvania are participating in ClinicalConnect, an HIE that provides local control over who accesses patients' information while allowing secure data exchange capabilities to be built into each organization's workflows, Carmody explains.

HIE users are authenticated and access patient information through their own organization's electronic health record systems and related security technologies. Once they gain authorized access, they can access ClinicalConnect through a hyperlink to launch a search of other data available about the patient from participating organizations.

New Challenges

"As we're taking on more and more data, as we take on more and more members, it obviously will create a lot of complexities in terms of bringing that data in and validating that it's quality data," Carmody says.

As the population of ClinicalConnect users grow, another challenge will be ensuring appropriate access to data. "Was it appropriate, was it valid?" Carmody asks. "That's part of our continuous effort to look at what our controls and practices are."

In the interview, Carmody also:

  • Describes ClinicalConnect's opt-out patient consent model. The HIE and its member organizations "try to educate patients about what is going to happen to their information being passed along to other providers through Clinical Connect," he says.
  • Tells why the HIE's technical team works closely with participating clinicians on functionality issues. "Engaging nurses and doctors and other clinicians in the planning early on is important," he says. "This is not an IT project; this is a healthcare effort, and it so critical for them to be engaged throughout the entire process."
  • Outlines how ClinicalConnect participants validate patients' information.

In addition to serving as president of ClinicalConnect, Carmody is vice president of information technology outreach services and program governance and reporting at University of Pittsburgh Medical Center. He has 16 years of IT experience. Before joining UPMC in 1998 as an information systems auditor, Carmody was a local area network administrator at Mellon Financial. He's also an adjunct associate professor at Point Park University and Duquesne University, teaching information systems and business courses.

ClinicalConnect HIE

MARIANNE KOLBASUK MCGEE: Tell us a bit about your HIE.

CHRIS CARMODY: ClinicalConnect was a concept that a group of healthcare systems and hospitals in western Pennsylvania came together and started focusing on about two and a half years ago to try to solve the problem with exchanging information across organizations to obviously meet the regulation that will be put in place with Stage 2 Meaningful Use [HITECH Act electronic health record incentive program]. ... The hospital groups got together and started discussing how we could do this from a technology perspective, from a financial perspective and then from an overall governance perspective, which is where I would equate a lot of the concern around the security and privacy of the data that we would be working with - handling and exchanging among the various members.

It took about a full year just to work through the trust factor in terms of getting every organization, of which we have nine members, to trust in one another and to work with one another in exchanging the data. ... We worked very closely and formed a CIO workgroup with IT representatives from each of the organizations. [We] dove right in to figure out how we were going to do this and how we were going to make this work with disparate electronic health record systems implemented across all the nine members - which by, the way are all different systems - and, most importantly, from a patient data security and privacy perspective, how we would do this in the most secure, efficient and effective way.

Fortunately, we were already ahead of the game a little bit at my organization, UPMC, where we were able to leverage a technology called dbMotion and a technology called Initiate, which is an enterprise master patient index, which we had used here for about 10 years. dbMotion is really the brains and the engine behind the scenes of how we integrate patient information across UPMC, which has, just among our health system, three different electronic health record systems.

Leveraging those two technologies and working through the conceptual design and the detailed design implementation of how this would work, immediately we focused in on how we could secure that data. A lot of teams are set up to where there are record locator services that are basically querying the databases behind the scenes looking for a particular patient record, and then moving that patient information to the appropriate provider or care giver. What we wanted to do with ClinicalConnect, leveraging the technologies that we had, is, first of all, make it as easy as possible for the clinician or the caregiver to access that data without having to click through multiple screens and open up another application to get at the data, but also to prevent the issues where we're exposing patients' information in scenarios where it could potentially be out of our control.

Our design with ClinicalConnect is actually pretty interesting, and I believe pretty unique to how we've done it here, and that's through the local EHR. For example, if you would have MEDITECH installed at Butler Hospital - which is one of our members - Butler's users access their patient records through their normal workflow. During a point in that workflow, when they're already in the patient record, when they've already been authenticated and they're known by that local system, there's a hyperlink - a button - that launches their search into ClinicalConnect and pulls that specific patient's data [from other sources]. ... A new window opens for them to view an aggregated view of all the other data that we've collected on that patient across our member organizations. Our design and focus has been on keeping the security, privacy and controls at the local level as much as possible in terms of managing the users and the access to the HIE data.

Hybrid Data Model

MCGEE: What data architecture model does ClinicalConnect use?

CARMODY: With ClinicalConnect we use a hybrid data model and that's based upon leveraging the existing technologies that we have in place. As I mentioned, we use dbMotion and Initiate among my organization UPMC, where we have over 6 million unique patient records in our database today. Instead of replicating that data and moving it into ClinicalConnect's version of dbMotion and Initiate, we have this hybrid set-up. As part of the launch process to pull a patient's record out, the dbMotion version for ClinicalConnect actually queries UPMC's version to go out and request the patient's information and pulls that back in, aggregates it with other patient records from our participating members and then presents it back to the end user in their view within their electronic health record system.

Safeguarding Data Security, Privacy

MCGEE: How does the model that you use safeguard data security and privacy compared with other models you considered and rejected?

CARMODY: The approach with our model is two-fold. ... Number one, just from a pure administrative perspective and a cost perspective, we have planned over 10,000 potential users of our clinical data within the ClinicalConnect health information exchange. That's a lot of user accounts. And [that would require] administration around the identity of those users and what their access privileges should be based upon their clinical needs, and that would have added a pretty substantial layer of work and effort around managing that moving forward.

Our thought process was, how can we leverage what's already there? Who knows those providers and those users of this data better than the member organizations that we're working with at the local level? So instead of trying to manage the identity of our users from a central location, we felt it best to leverage what's already in place based upon HIPAA privacy and security regulations at that local level and pass those credentials along with the specific patient information to do the query requests against our ClinicalConnect database. That data is sent back out and presented in a very user-friendly format for that provider and clinician. We took a very lean approach as we described it in managing and dealing with the security and privacy factor.

The second half of that is how we're managing that data behind the scenes instead of having a broad-based query and search. What we do in our structure and in our model is we're identifying and validating the identity of those patients and their information as they get registered at the point of care. We capture that, we run that against our Initiate EMPI system to validate and verify that's that patient's information, and we use a lot of different unique identifiers and algorithms to give us a high level of confidence that's the patient's information. Again, we protect that patient information that we've collected and gathered through the CCD, the continuity of care document, digitized data that we're taking in and aggregating in our database by limiting that query to that specific patient in that context.

Obtaining Patient Consent

MCGEE: What's your approach to obtaining patient consent for exchanging their information? For instance, do you have an opt-in or an opt-out approach? Is there any sort of granular consent where patients can authorize some data to be exchanged, but not other data?

CARMODY: That's a very interesting question and that was another hotly debated decision that had to be made. ...

We were fortunate enough that we weren't the first health information exchange in the country, so we were able to do a lot of research and look at the pluses and minuses of both an opt-in and opt-out model. Our decision that we arrived at was around an opt-out model. We felt very comfortable and our physicians and clinicians that participate in that decision making process agreed that it was the best way to get patients engaged and involved, and to ultimately serve those patients through exchanging their data.

Pennsylvania - the state that we operate in - just a few months ago passed Senate Bill 8 that confirms the opt-out model across the state of Pennsylvania. Many different states and many different HIEs have different opt-in and opt-out approaches. We felt it was the right decision to make, taking an opt-out approach.

What we do use are many different means to communicate with patients through our website, through educating our providers, our doctors, our nurses and our other care providers that are interacting with patients, informing them so they can explain to the patient why their data is part of a health information exchange; in our case ClinicalConnect. I'm happy to report that our process has just over 98 percent of the people participate. Only about 1.98 percent have opted out of their data being exchanged as part of ClinicalConnect.

Data Shared

MCGEE: What sort of data do ClinicalConnect participants share?

CARMODY: We share patient encounter information. We have medications, allergies and various lab results. We have various clinical reports and documentations, like radiology-type reports, that are currently available in ClinicalConnect. We display that data in a summarized view for the clinician when they access ClinicalConnect, and they can see where that data came from. They can see that it came from Butler Hospital or Heritage Valley Health System or UPMC, and they can see the date that it occurred in those results and the provider or caregiver who created that data.

As we look forward into the future and with our participation at our board level with various physicians and clinicians, we're always looking for ways to improve and enhance what data is made available to them. There's actually a very interesting and real situation ... I heard about through our radiology department that has a relationship with one of our member hospitals. A patient presented at Heritage Valley Health Systems emergency department and complained of shoulder pain. The physician treating the patient utilized ClinicalConnect to go up and see that the patient actually had an MRI done on their shoulder just seven days previously at a UPMC facility and was able to review the MRI report and it actually prevented the doctor from reordering and putting the patient through another MRI exam. They were able to treat the patient effectively and move on. Those are the types of anecdotal stories that are trickling in as we're deploying ClinicalConnect across organizations. That's very exciting for me. It validates why we're doing this, why we need to do this. And it will ultimately help us treat our patients much better. ...

Biggest Security, Privacy Challenges

MCGEE: What are the biggest security and privacy challenges for ClinicalConnect moving ahead?

CARMODY: ... As we're taking on more and more data, as we take on more and more members to ClinicalConnect, it obviously will create a lot of complexities in terms of bringing that data in and validating that it's quality data. That's something we're managing with our group of nine hospitals and health systems today regarding the quality of data, and if the data does not have a match or is not valid we don't take it in. We reject it because we don't want to introduce data conflicts and quality issues from a pure data perspective.

On the security side, we've been fortunate to date that there have been no breaches or any issues that have been brought to light with our current usage. What I expect to happen in the future as our membership grows and as our usage grows is there will be times and events that occur that put into question who's accessing that data. Was it appropriate? Was it valid? That's part of our continuous effort to look at what our controls and practices are to prevent those types of issues, keeping our engagement with our member organizations to ensure that the local effort and those local processes in terms of how they manage security and privacy through their electronic health record are effective, efficient and are adequate to protect the information of data moving forward.

... I believe that we have the appropriate safeguards and controls that limit people from doing broad-based queries through ClinicalConnect, and that we're logging and auditing that access that's occurring. We can always go back from a detective perspective and recreate a situation and understand where that inappropriate access may have come from and work with the local members of ClinicalConnect to ensure that those types of events don't occur and aren't impacting our patients.

Best Practices

MCGEE: What advice do you have to start-up health information exchanges in terms of best practices for data security and privacy when planning their strategies?

CARMODY: My best advice is to let HIPAA be your guide. That has been our measuring stick, our benchmark that we've always used - to make sure that we're in compliance with HIPAA privacy and security regulations; that we're not diminishing the controls and safeguards that are in place today for users of electronic health records systems; and that, if [possible], we can improve on those or enhance those as part of the process.

Also, engaging physicians, nurses and all clinicians in the discussions around privacy and security when you're starting, building and deploying your HIE is so critical. This is not an IT project. This is not an IT effort. This is a healthcare effort, and it's so critical and important for them to be engaged and involved throughout the entire process.

Educate and engage the users and the patients through the health information exchange, and [that includes] communicating to them the benefit on why this is important. [Explain to patients] that their information will be made available in a secure manner and fashion for the pure purposes of treating them in a serious acute event or treatments that they may be receiving for some chronic disease or any other type of health issue that may occur throughout their life.

The last point in terms of best practices for starting up a HIE and ensuring appropriate data security and privacy is you don't have to reinvent the wheel. Look back to how you've accomplished implementing electronic health record systems and other IT systems in a healthcare setting and try to leverage those best practices and proven practices that are in place today, and how that could be applied to your health information exchange.


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.