How should test data be identified?

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Security
    • (NA)
    • Hide

      Persuasive with Mod

      add section to secuity&privacy module page

      "Using FHIR to publish test data"

      There are times when test data is needed. Test data are data that is not associated with any real patient. Test data are usually representative of expected data that is published for the purpose of testing. Test data may be fully fabricated, or derived from use-cases that had previously caused failures.

      When test data are published it may be important to identify the data as test data. This identification may be to assure that the test data is not misunderstood as real data, and that the test data is not factored into statistics or reporting. However there is a risk that identifying test data may inappropriately thward the intended test that the data are published to test.

      Test data could be isolated in a server specific to test data.

      Test data could be intermingled with real-patient data using one or both of the followingmethods:

      • Security-label – All test data Resouces could be tagged with PurposeOfUse HTEST
      • Test Patient – The Patient that the data is associated with could be a clear indication of a test patient. (For example, in the USA the SSN starting with "666-" will never be issued so is commonly used as an indicator of a test patient)

      Note there is a risk when comingling test data with real patient data that someone will accidently use test data without realizing it is test data.

      Show
      Persuasive with Mod add section to secuity&privacy module page "Using FHIR to publish test data" There are times when test data is needed. Test data are data that is not associated with any real patient. Test data are usually representative of expected data that is published for the purpose of testing. Test data may be fully fabricated, or derived from use-cases that had previously caused failures. When test data are published it may be important to identify the data as test data. This identification may be to assure that the test data is not misunderstood as real data, and that the test data is not factored into statistics or reporting. However there is a risk that identifying test data may inappropriately thward the intended test that the data are published to test. Test data could be isolated in a server specific to test data. Test data could be intermingled with real-patient data using one or both of the followingmethods: Security-label – All test data Resouces could be tagged with PurposeOfUse HTEST Test Patient – The Patient that the data is associated with could be a clear indication of a test patient. (For example, in the USA the SSN starting with "666-" will never be issued so is commonly used as an indicator of a test patient) Note there is a risk when comingling test data with real patient data that someone will accidently use test data without realizing it is test data.
    • Johnathan Coleman/Joe Lamy: 2-0-0
    • Enhancement
    • Non-substantive
    • DSTU2

      How should 'test-data' be identified? Is this a legitimate use of security-tags?

      It is clear that security-tags already support de-identified methods. The question is specifically about completely fabricated data.

      See FHIR chat thread https://chat.fhir.org/#narrow/stream/implementers/topic/Distinguishing.20test.20patients

      Discussion during Security WG call on August 30 indicates that we should add an 'informative' section that indicates 'some methodods' that are invisioned, and some of the concerns with each. Likely just a paragrah and a few bullets. Isolated test data system. Integrated test data system with tagged data. Integrated test data without tagging.

            Assignee:
            Unassigned
            Reporter:
            John Moehrke
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: