Skip to main content
SpringerLink
Log in

Evaluating existing security and privacy requirements for legal compliance

  • Special Issue—Security Requirements Engineering
  • Published:
Requirements Engineering Aims and scope Submit manuscript

Abstract

Governments enact laws and regulations to safeguard the security and privacy of their citizens. In response, requirements engineers must specify compliant system requirements to satisfy applicable legal security and privacy obligations. Specifying legally compliant requirements is challenging because legal texts are complex and ambiguous by nature. In this paper, we discuss our evaluation of the requirements for iTrust, an open-source Electronic Health Records system, for compliance with legal requirements governing security and privacy in the healthcare domain. We begin with an overview of the method we developed, using existing requirements engineering techniques, and then summarize our experiences in applying our method to the iTrust system. We illustrate some of the challenges that practitioners face when specifying requirements for a system that must comply with law and close with a discussion of needed future research focusing on security and privacy requirements.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4
Fig. 5
Fig. 6

Similar content being viewed by others

Notes

  1. http://www.nlm.nih.gov/hmd/greek/greek_oath.html.

  2. Pub. L. No. 104–191, 110 Stat. 1936.

  3. Note that Choi et al. use the term electronic medical records (EMR) system rather than electronic health records (EHR) system [CCK06]; we treat these terms as interchangeable for the purposes of this paper.

  4. This paper uses “legal texts” to refer to both legislation and regulations.

  5. All subsequent references in this paper to HIPAA regulatory sections are from Title 45 of the Code of Federal Regulations (C.F.R.).

  6. United States v. Gibson, No. CR04-0374RSM, 2004 WL 2188280 (W.D. Wash. Aug. 19, 2004).

  7. Pub. L. 106–102, 113 Stat. 1338 (1999).

  8. Note that our work has a more limited definition of stakeholder than that used by Breaux and Antón. Specifically, we only consider stakeholders that are explicitly mentioned in the requirements document and in the relevant legal texts, whereas Breaux and Antón use stakeholder to refer to any entity with a ‘stake’ in the outcome [6].

  9. This inheritance is similar to that found in UML class diagrams. The difference is that legal rights and obligations (instead of data or methods) are inherited by the subclass.

  10. The CHCP definition appears in a section of HIPAA beyond the scope of our analysis, but HIPAA compliance beyond Part 164 would require its contemplation by requirements engineers during the use of our methodology.

References

  1. Choi YB, Capitan KE, Krause JS, Streeper MM (2006) Challenges associated with privacy in health care industry: implementation of HIPAA and the security rules. J Med Syst 30(1):57–64

    Article  Google Scholar 

  2. DesRoches CM, Campbell EG, Rao SR, Donelan K, Ferris TG, Jha A, Kaushal R, Levy DE, Rosenbaum S, Shields AE, Blumenthal D (2008) Electronic health records in ambulatory care—a national survey of physicians. N Engl J Med 359(1):50–60

    Article  Google Scholar 

  3. Williams L, Shin Y (2006) WIP: exploring security and privacy concepts through the development and testing of the iTrust medical records system. Front Educ S1F30–31

  4. Otto PN, Antón AI (2007) Addressing legal requirements in requirements engineering. In: Proceedings of the 15th IEEE international requirements engineering conference, pp 5–14

  5. Antón AI, Earp JB (2001) In: Ghosh AK (ed) Recent advances in E-commerce security and privacy. Kluwer, Dordrecht, pp 29–46

  6. Breaux TD, Antón AI (2008) Analyzing regulatory rules for privacy and security requirements. IEEE Trans Softw Eng 34(1):5–20

    Article  Google Scholar 

  7. Robinson W (2005) Implementing rule-based monitors within a framework for continuous requirements monitoring. In: Proceedings of the 38th Hawaii international conference on system sciences, pp 188–197

  8. Otoya S, Cerpa N (1999) An experience: a small software company attempting to improve its process. In: Proceedings of the software technology and engineering practice, pp 153–160

  9. Beaver K, Herold R (2004) The practical guide to HIPAA privacy and security compliance. Auerbach, Philadelphia

    Google Scholar 

  10. Garner BA (ed) (2004) Black’s law dictionary, 8th edn. Thompson West

  11. Breaux TD, Antón AI, Karat C-M, Karat J (2006) Enforceability vs. accountability in electronic policies. In: Proceedings of the seventh IEEE international workshop on policies for distributed systems and networks, pp 227–230

  12. Breaux TD, Vail MW, Antón AI (2006) Towards regulatory compliance: extracting rights and obligations to align requirements with regulations. In: RE’06: Proceedings of the 14th IEEE international requirements engineering conference, pp 49–58

  13. Barth A, Datta A, Mitchell JC, Nissenbaum H (2006) Privacy and contextual integrity: framework and applications. In: Proceedings of the 2006 IEEE symposium on security and privacy, pp 184–198

  14. May MJ, Gunter CA, Lee I (2006) Privacy APIs: access control techniques to analyze and verify legal privacy policies. In: 19th IEEE computer security foundations workshop (CSFW’06), pp 85–97

  15. Massacci F, Prest M, Zannone N (2005) Using a security requirements engineering methodology in practice: the compliance with the Italian data protection legislation. Comput Stand Interfaces 27(5):445–455

    Article  Google Scholar 

  16. Antón AI, Carter R, Dagnino A, Dempster J, Siege D (2001) Deriving goals from a use-case based requirements specification. Requirements Eng 6(1):63–73

    Article  MATH  Google Scholar 

  17. Glinz M (2000) Problems and deficiencies of uml as a requirements specification language. In: Tenth international workshop on software specification and design, pp 11–22

  18. Alspaugh TA, Antón AI (2008) Scenario support for effective requirements. Inf Softw Technol 50(3):198–220

    Article  Google Scholar 

  19. Ben Achour C, Rolland C, Maiden NAM, Souveyet C (1999) Guiding use case authoring: results of an empirical study. In: Proceedings of the IEEE international symposium on requirements engineering, pp 36–43

  20. Berenbach BA (2004) Comparison of uml and text based requirements engineering. In: OOPSLA ’04: companion to the 19th annual ACM SIGPLAN conference on object-oriented programming systems, languages, and applications, ACM, pp 247–252

  21. Maiden NAM (1998) CREWS-SAVRE: scenarios for acquiring and validating requirements. Autom Softw Eng 5(4):419–446

    Article  Google Scholar 

  22. Potts C, Takahashi K, Antón A (1994) Inquiry-based requirements analysis. IEEE Softw 11:21–32

    Article  Google Scholar 

  23. Sutcliffe A (2003) Scenario-based requirements engineering. In: Proceedings of the 11th IEEE international requirements engineering conference, pp 320–329

  24. Antón AI, Earp JB, Carter RA (2003) Precluding incongruous behavior by aligning software requirements with security and privacy policies. Inf Softw Technol 45(14):967–977

    Article  Google Scholar 

  25. Breaux TD (2009) Legal requirements acquisition for the specification of legally compliant information systems. PhD thesis, North Carolina State University

  26. Breaux TD, Antón AI (2005) Mining rule semantics to understand legislative compliance. In: WPES ’05: proceedings of the 2005 ACM workshop on privacy in the electronic society, pp 51–54

  27. Williams L, Xie T, Meneely A, Hayward L (2008a) iTrust medical care requirements specification. http://agile.csc.ncsu.edu/iTrust/wiki/doku.php?id=requirements

  28. Williams L, Xie T, Meneely A, Hayward L, Massey A (2008b) iTrust medical care requirements specification. http://agile.csc.ncsu.edu/iTrust/wiki/doku.php?id=lauren791e

  29. Allenby K, Kelly T (2001) Deriving safety requirements using scenarios. In: Proceedings of the fifth IEEE international symposium on requirements engineering, pp 228–235

  30. Antón AI (1996) Goal-based requirements analysis. In: Proceedings of the second international conference on requirements engineering, pp 136–144, 15–18

  31. Antón AI, Potts C (1998) The use of goals to surface requirements for evolving systems. In: Proceedings of the 1998 international conference on software engineering, pp 157–166, 19–25

  32. van Lamsweerde A. (2001) Goal-oriented requirements engineering: a guided tour. In: Proceedings of the fifth IEEE international symposium on requirements engineering, pp 249–262

  33. Weidenhaupt K, Pohl K, Jarke M, Haumer P (1998) Scenarios in system development: current practice. IEEE Softw 15:34–45

    Article  Google Scholar 

  34. Whittle J, Schumann J (2000) Generating Statechart designs from scenarios. In: Proceedings of the 2000 international conference on software engineering, pp 314–323

Download references

Acknowledgments

The authors would like to thank Mr. Andy Meneely for hosting our wiki site throughout our study and Dr. Williams, Dr. Xie, and Mr. Meneely for their work in building iTrust, as well as ThePrivacyPlace.Org Reading Group members. This work was supported by NSF ITR Grant #0325269, NSF Cyber Trust Grant #0430166, and NSF Science of Design Grant #0725144.

Author information

Authors and Affiliations

  1. Department of Computer Science, North Carolina State University, Raleigh, NC, USA

    Aaron K. Massey, Paul N. Otto, Lauren J. Hayward & Annie I. Antón

  2. School of Law, Duke University, Durham, NC, USA

    Paul N. Otto

Authors
  1. Aaron K. Massey
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Paul N. Otto
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Lauren J. Hayward
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Annie I. Antón
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Aaron K. Massey.

Appendix: Sample legal requirements

Appendix: Sample legal requirements

Below is a set of three sample legal requirements extracted from the original iTrust requirements documentation.

1.1 Requirement 6

  • Description: iTrust shall maintain a patient’s records for a period of 7 years after their record has been disabled.

  • Rationale: HIPAA requires records to be maintained for 6 years, but does not clearly specify when that 6 year time period starts.

  • Context: This is done to provide a buffer, which can guarantee compliance with HIPAA.

  • Priority: High-L

  • Origin: Original (UC1), Legal (HIPAA §164.316)

1.2 Requirement 7

  • Description: iTrust shall automatically destroy a patient’s records after their record has been disabled for a period of 7 years.

  • Rationale: HIPAA only requires that records are maintained for 6 years, but a hospital must maintain records accurately if they are maintained at all. This requirement allows a hospital to allocate resources to maintain active records rather than disabled records.

  • Context: If a hospital has a record for a patient whose record was disabled 7 years ago (i.e., past the HIPAA-required time period), but that record is inaccurate, then the hospital may be held liable for the inaccuracies even though the hospital did not have to maintain the record at all. Therefore, all records that are definitively past the HIPAA-required maintenance time period are destroyed.

  • Priority: High-L

  • Origin: Legal (HIPAA §164.316)

  • Legal Issue: Records are probably backed up somewhere. Does this apply to backups as well? (We believe yes.)

  • Legal Issue: Should a cryptographic scrubber be used or should the record simply be deleted using common operating system commands?

1.3 Requirement 14

  • Description: iTrust shall generate a unique user ID and default password upon account creation.

  • Rationale: Users need to have the ability to identify and authenticate themselves to iTrust.

  • Context: This supports basic iTrust operations: iTrust must be able to differentiate between accounts.

  • Priority: Critical-L

  • Origin: Original (UC1), Legal (HIPAA §164.312)

Rights and permissions

Reprints and permissions

About this article

Cite this article

Massey, A.K., Otto, P.N., Hayward, L.J. et al. Evaluating existing security and privacy requirements for legal compliance. Requirements Eng 15, 119–137 (2010). https://doi.org/10.1007/s00766-009-0089-5

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-009-0089-5

Keywords

Search

Navigation