4 Replies Latest reply on Dec 19, 2016 4:24 AM by wimdecorte

    Restricting developer access to confidential data

    pbedouk

      Hi

       

      I wonder how you might handle this situation ...

       

      I am developing a small-ish solution which will contain confidential patient medical information.

       

      The client is using FM13 on her laptop (for other things).

      The data currently exists in an excel spreadsheet.

       

      QUESTION: Once the solution is deployed and loaded with data, how could I make future updates/changes without seeing the confidential stuff (patients name)? 

       

      For the initial deployment I would proceed as follows (suggestion welcome!):

       

      CLIENT: In her spreadsheet, add a new column and populate with a unique ID corresponding to the patient's name.

      CLIENT: Copy the name and ID columns to another spreadsheet, which I would not see.

      CLIENT: Erase the name column in the main spreadsheet

       

      ME: Build the solution using this modified spreadsheet as test data.

      BOTH: Test, modify etc. When ready ...

       

      CLIENT: add unique ID to any new patients in her spreadsheet who may have arrived during the build and testing phase. Erase their names.

       

      ME: Import (via a script) the current updated spreadsheet (which has the unique IDs in place of names).

      ME: Deploy the solution via dropbox.

       

      CLIENT: Move the file out of dropbox. (so I can't see it anymore)

      CLIENT: Import (via a script) the second spreadsheet to populate the name field.

       

      I think this satisfies the confidentiality requirement.

       

      But how would I make, test and deploy changes in the future without seeing the patient name??

        • 1. Re: Restricting developer access to confidential data
          Markus Schneider

          as a developer with master-access, one can do everything, see everything

           

          what about a separate contract, agreement?

          • 2. Re: Restricting developer access to confidential data
            keywords

            What you propose seems like overkill to me. I think you need to discuss the confidentiality aspect of things with your client and proffer your own trustworthy character. Your personal undertaking to treat all data as confidential is your best guarantee. As Markus points out, no matter what you do, you have—and must have—full access so there is no guarantee you won't stumble on personal data. One thing you could do is work with some dummy records during development, but it seems to me all the other ideas are just making a lot of unnecessary work.

            • 3. Re: Restricting developer access to confidential data
              RubenVanDenBoogaard

              An option could be to create a script to store the sensitive information encrypted in FileMaker (using a CF or plugin)

              where only the client knows the password.

              when the client logs in ask for the password and show the decrypted fields in unstored calculations.

               

              Have the client store the password very good, if they lose it, you can not retrieve it . . .

              • 4. Re: Restricting developer access to confidential data
                wimdecorte

                pbedouk wrote:

                 

                But how would I make, test and deploy changes in the future without seeing the patient name??

                 

                There are special considerations to make when dealing with this kind of HiPAA solutions and clients.  One of them is to sign a Vendor Business Associate agreement and carry the proper insurance that will be required.

                 

                Even then - for your own protection - you should set up a system whereby you stay away from the real data as much as you can:

                - you develop on a development copy of the solution that holds only dummy data.  Not the real data.  That is a challenge because you will have to create the dummy data so that it is relevant and representative both in nature and quantity

                - develop a data migration routine that the client can run; when you have a new version you hand it over without data to the client.  The client runs the routine that gets the data from the live files into the new files.