Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My responsibilities at a small company are mostly programming-related, but I also perform a number of other roles that definitely require access to PHI1. In larger organizations with clearer delineation of responsibilities, is it prudent to provide programmers with only dummy data and never actual PHI?

1 Protected Health Information, as outlined by the US legislation that governs patient privacy, HIPAA.

share|improve this question
    
This was originally posted on the closed Healthcare IT site. There is a new Healthcare Industry stack exchange where this question would be a good fit. If you're interested, you should consider joining the proposal –  Oleksi Jul 7 '12 at 4:14
add comment

migrated from healthcareit.stackexchange.com Apr 30 '12 at 9:36

This question came from our site for healthcare IT professionals and solution providers.

7 Answers

up vote 18 down vote accepted

I don't think programmers should use unanonymized data in day to day development and testing.

I would not exclude the possibility though. In situations where you need programmers to help with acute support cases, it can be a very bad idea to work with something else than the true patient data.

Imagine you need to explain to your customer that you needed to provide them with multiple patches for the same problem, because your programmers weren't allowed to work with production data, and fixed the wrong bug.

share|improve this answer
add comment

In general no, programmers should not need access to real patient data.

Practically however, in some cases programmers require access to real, non-anonymized data when bugs can only be reproduced with particular data (problems related to character encodings, especially with something like DICOM which can have a lot of edge conditions with Japanese names). In these cases there should be policies and procedures in place to deal with these situations (customer agreement and notifications, encryption methods if the data leaves the customer site, retention policies - usually delete the data as soon as it is no longer needed, etc.).

share|improve this answer
add comment

In our company there's a special section in the employment contract that states that data from production systems is confidential and should be treated like that.

In the past our development teams worked against copies of production data which makes developing very easy, but makes automated tests very hard. We're now moving to fixed sets of data that can be used in automated tests and in daily development. When building these datasets we try to take real life examples and anonymise them. We see that developing against these datasets (if there are enough) is as easy as developing against real time data.

share|improve this answer
add comment

There is no reason for programmers to see real patient data. Yes they need to work with data to test and develop systems but dummy data can be built from real data e.g. scambled identifiers, swapping data with other patients etc. Worse case you would have to create dummy data from scratch and this could never cover all scenarios for testing etc. In my opinion (note, I'm not a lawyer) I can't see how using identifiable patient would be ethical or legal in the UK under the Data Protection Act and/or following the Caldicott Principles.

share|improve this answer
2  
What programmer is responsible for creating appropriate dummy data? How do you know that dummy data covers all use cases and anomalies in real data? –  Jeff Ferland Oct 14 '11 at 14:33
    
Indeed that is the problem. I think a senior dba or the programmer who has been appropriately trained in data governance, has been authorised by governing bodies etc needs to do this work - and as blindly as possible. Think it comes down to clear processes, good governance, separation of roles and training. Also, I completely agree you'd struggle to cover all test cases or weird scenarios that may occur in the data. –  ajudson Oct 14 '11 at 15:23
    
Agree with other answers, that in some support cases developers will need to be involved and will need to work with non-anonymised patient data. So as above, you need good proceedures. –  ajudson Oct 14 '11 at 16:33
    
@epigrad has a good point: there could be one intermediary (or a small number) given the responsibility of creating synthetic data. –  Iterator Nov 6 '11 at 15:27
add comment

Absolutely not on a routine basis. A simulated data set for development purposes is almost trivially easy to construct from real data, and entirely purges PHI from the process.

I wouldn't even have the programmers do that - I would probably turn to a biostatistician or another member of the institution's staff who already has access to those kinds of records. The PHI should be pulled once, to make sure you're developing for something that looks like what the final data should look like, but records from real people shouldn't be used. Too much risk of exposure for very little return.

share|improve this answer
1  
At a high level, this is quite correct. Much could be explained about why it's a bad idea, and the repercussions. Still, you've addressed how one could satisfy the needs of reasonable synthetic data for development purposes. Leave it to someone else to ensure that synthetic data reflects the real data in a useful way, and the programmers should ensure that they can handle the synthetic data correctly, rather than naively retain real patient data as a test case (e.g. in test-driven development). –  Iterator Nov 6 '11 at 15:26
add comment

HIPAA makes it pretty clear that access to PHI should be limited as much as possible without putting an undue burden on being able to perform the required tasks. That would apply to programmers as much as doctors.

This is even more important since thanks to the HITECH Act business associates are now required to comply with HIPAA just like the other healthcare providers.

share|improve this answer
add comment

The answer is it depends. If you can refresh the development environments using good masking algorithms, there shouldn't be any need to use production data. The relationships should be considered for masking so that the data is still in tact and just the PHI is masked using algorithms. This ensures that you are using production data and still ensuring PHI compliance.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.