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.

  • 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
    Commented Jul 7, 2012 at 4:14

7 Answers 7


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.


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.).


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.


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.

  • 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? Commented Oct 14, 2011 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. Commented Oct 14, 2011 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. Commented Oct 14, 2011 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
    Commented Nov 6, 2011 at 15:27

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.

  • 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
    Commented Nov 6, 2011 at 15:26

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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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