Health Information Privacy and Security

  • 609 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
609
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
24
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Health Information  Privacy & Security Nawanan Theera‐Ampornpunt, M.D., Ph.D. Faculty of Medicine Ramathibodi Hospital Mahidol University For the Faculty of Pharmacy, Silpakorn University February 4, 2014 http://www.SlideShare.net/Nawanan
  • 2. Outline         Introduction to Information Privacy & Security Protecting Information Privacy & Security User Security Software Security Cryptography Malware Security Standards Privacy & Security Laws
  • 3. Introduction to  Information Privacy &  Security
  • 4. Threats to Information Security Malware
  • 5. Sources of the Threats       Hackers Viruses & Malware Poorly‐designed systems Insiders (Employees) People’s ignorance & lack of knowledge Disasters & other incidents affecting  information systems
  • 6. Consequences of Security Attacks  Information risks    Operational risks       Identity thefts Financial losses Disclosure of information that may affect employment or other  personal aspects (e.g. health information) Physical/psychological harms Organizational risks    System not functional (Denial of Service ‐ DoS) System wrongly operated Personal risks   Unauthorized access & disclosure of confidential information Unauthorized addition, deletion, or modification of information Financial losses Damage to reputation & trust Etc.
  • 7. Privacy & Security    Privacy: “The ability of an individual or group  to seclude themselves or information about  themselves and thereby reveal themselves  selectively.” (Wikipedia) Security: “The degree of protection to safeguard  ... person against danger, damage, loss, and  crime.” (Wikipedia) Information Security: “Protecting information  and information systems from unauthorized  access, use, disclosure, disruption, modification,  perusal, inspection, recording or destruction”  (Wikipedia)
  • 8. Information Security    Confidentiality Integrity Availability
  • 9. Examples of Confidentiality Risks http://usatoday30.usatoday.com/life/people/2007‐10‐10‐clooney_N.htm
  • 10. Examples of Integrity Risks “Operation Aurora” Alleged Targets: Google, Adobe, Juniper Networks,  Yahoo!, Symantec, Northrop Grumman, Morgan Stanley,  Dow Chemical Goal: To gain access to and potentially modify source  code repositories at high tech, security & defense  contractor companies http://www.wired.com/threatlevel/2010/03/source‐code‐hacks/ http://en.wikipedia.org/wiki/Operation_Aurora
  • 11. Examples of Integrity Risks Web Defacements http://news.softpedia.com/news/700‐000‐InMotion‐Websites‐Hacked‐by‐TiGER‐M‐TE‐223607.shtml
  • 12. Examples of Availability Risks Viruses/worms that led to instability &  system restart (e.g. Blaster worm) http://en.wikipedia.org/wiki/Blaster_worm
  • 13. Examples of Availability Risks Ariane 5 Flight 501 Rocket Launch Failure Cause: Software bug on rocket acceleration due to data conversion  from a 64‐bit floating point number to a 16‐bit signed integer without  proper checks, leading to arithmatic overflow http://en.wikipedia.org/wiki/Ariane_5_Flight_501
  • 14. Interesting Resources       http://en.wikipedia.org/wiki/List_of_software_bugs http://en.wikipedia.org/wiki/Notable_computer_viruses_ and_worms http://en.wikipedia.org/wiki/Hacktivism http://en.wikipedia.org/wiki/Website_defacement http://en.wikipedia.org/wiki/Hacker_(computer_security) http://en.wikipedia.org/wiki/List_of_hackers
  • 15. Protecting Information  Privacy & Security
  • 16. Common Security Terms    Attack  An attempt to breach system security Threat  A scenario that can harm a system Vulnerability  The “hole” that is used in the attack
  • 17. Class Exercise  Identify some possible means an  attacker could use to conduct a  security attack
  • 18. Simplified Attack Scenarios Alice Server Bob Eve/Mallory
  • 19. Simplified Attack Scenarios Alice ‐ ‐ ‐ Server Physical access to client computer Electronic access (password) Tricking user into doing something  (malware, phishing & social  engineering) Bob Eve/Mallory
  • 20. Simplified Attack Scenarios Alice ‐ ‐ ‐ Server Intercepting (eavesdropping or  “sniffing”) data in transit Modifying data (“Man‐in‐the‐ middle” attacks) “Replay” attacks Bob Eve/Mallory
  • 21. Simplified Attack Scenarios Alice ‐ ‐ Server Bob Unauthorized access to servers through ‐ Physical means ‐ User accounts & privileges ‐ Attacks through software vulnerabilities ‐ Attacks using protocol weaknesses Eve/Mallory DoS / DDoS attacks
  • 22. Simplified Attack Scenarios Alice Server Bob Other & newer forms of  attacks possible Eve/Mallory
  • 23. Safeguarding Against Attacks Alice Server Bob Administrative Security ‐ Security & privacy policy ‐ Governance of security risk management & response ‐ Uniform enforcement of policy & monitoring ‐ Disaster recovery planning (DRP) & Business continuity  planning/management (BCP/BCM) ‐ Legal obligations, requirements & disclaimers
  • 24. Safeguarding Against Attacks Alice Server Bob Physical Security ‐ Protecting physical access of clients & servers ‐ ‐ ‐ Locks & chains, locked rooms, security cameras Mobile device security Secure storage & secure disposition of storage devices
  • 25. Safeguarding Against Attacks Alice Server Bob User Security ‐ User account management ‐ Strong p/w policy (length, complexity, expiry, no meaning) ‐ Principle of Least Privilege ‐ “Clear desk, clear screen policy” ‐ Audit trails ‐ Education, awareness building & policy enforcement ‐ Alerts & education about phishing & social engineering
  • 26. Safeguarding Against Attacks Alice Server Bob System Security ‐ Antivirus, antispyware, personal firewall, intrusion  detection/prevention system (IDS/IPS), log files, monitoring ‐ Updates, patches, fixes of operating system vulnerabilities &  application vulnerabilities ‐ Redundancy (avoid “Single Point of Failure”) ‐ Honeypots
  • 27. Safeguarding Against Attacks Alice Server Bob Software Security ‐ Software (clients & servers) that is secure by design ‐ Software testing against failures, bugs, invalid inputs,  performance issues & attacks ‐ Updates to patch vulnerabilities
  • 28. Safeguarding Against Attacks Alice Server Bob Network Security ‐ Access control (physical & electronic) to network devices ‐ Use of secure network protocols if possible ‐ Data encryption during transit if possible ‐ Bandwidth monitoring & control
  • 29. Safeguarding Against Attacks Alice Server Bob Database Security ‐ Access control to databases & storage devices ‐ Encryption of data stored in databases if necessary ‐ Secure destruction of data after use ‐ Access control to queries/reports ‐ Security features of database management systems (DBMS)
  • 30. Privacy Safeguards  Security safeguards  Informed consent Privacy culture      User awareness building & education Organizational policy & regulations Enforcement Ongoing privacy & security assessments, monitoring,  and protection Image: http://www.nurseweek.com/news/images/privacy.jpg
  • 31. User Security
  • 32. User Security  Access control   Role‐based access control   Selective restriction of access to the system Access control based on the person’s role  (rather than identity) Audit trails  Logs/records that provide evidence of  sequence of activities
  • 33. User Security  Identification    Identifying who you are Usually done by user IDs or some other unique codes Authentication    Confirming that you truly are who you identify Usually done by keys, PIN, passwords or biometrics Authorization  Specifying/verifying how much you have access  Determined based on system owner’s policy & system  configurations  “Principle of Least Privilege”
  • 34. User Security  Nonrepudiation     Proving integrity, origin, & performer of an  activity without the person’s ability to refute  his actions Most common form: signatures Electronic signatures offer varying degrees of  nonrepudiation  PIN/password vs. biometrics Digital certificates (in public key  infrastructure ‐ PKI) often used to ascertain  nonrepudiation
  • 35. User Security   Multiple‐Factor Authentication Two‐Factor Authentication   Use of multiple means (“factors”) for authentication Types of Authentication Factors    Something you know  Password, PIN, etc. Something you have  Keys, cards, tokens, devices (e.g. mobile phones) Something you are  Biometrics
  • 36. Need for Strong Password Policy So, two informaticians walk into a bar... The bouncer says,  ʺWhatʹs the password.ʺ  One says, ʺPassword?ʺ  The bouncer lets them  in.  Credits: @RossMartin & AMIA (2012)
  • 37. Recommended Password Policy  Length   8 characters or more (to slow down brute‐force attacks) Complexity (to slow down brute‐force attacks)  Consists of 3 of 4 categories of characters  Uppercase letters  Lowercase letters  Numbers  Symbols (except symbols that have special uses by the  system or that can be used to hack system, e.g. SQL Injection)  No meaning (“Dictionary Attacks”)  Not simple patterns (12345678, 11111111) (to slow down  brute‐ force attacks & prevent dictionary attacks)  Not easy to guess (birthday, family names, etc.) (to prevent  unknown & known persons from guessing) Personal opinion. No legal responsibility assumed.
  • 38. Recommended Password Policy  Expiration (to make brute‐force attacks not possible)      Decreasing over time because of increasing computer’s  speed   6‐8 months But be careful! Too short duration will force users to write  passwords down Secure password storage in database or system  (encrypted or store only password hashes) Secure password confirmation Secure “forget password” policy Different password for each account. Create variations  to help remember. If not possible, have different sets of  accounts for differing security needs (e.g., bank  accounts vs. social media sites) Personal opinion. No legal responsibility assumed.
  • 39. Techniques to Remember Passwords  http://www.wikihow.com/Create‐a‐Password‐You‐Can‐ Remember   Note that some of the techniques are less secure! One easy & secure way: password mnemonic  Think of a full sentence that you can remember  Ideally the sentence should have 8 or more words, with  numbers and symbols  Use first character of each word as password  Sentence: I love reading all 7 Harry Potter books!  Password: Ilra7HPb!  Voila! Personal opinion. No legal responsibility assumed.
  • 40. Social Engineering Examples Dear mail.mahidol.ac.th Email Account User, We wrote to you on 11th January 2010 advising that you change the password on your account in order to prevent any unauthorised account access following the network instruction we previously communicated. all Mailhub systems will undergo regularly scheduled maintenance. Access to your e‐mail via the Webmail client will be unavailable for some time during this maintenance period. We are currently upgrading our data base and e‐mail account center i.e homepage view. We shall be deleting old [https://mail.mahidol.ac.th/l accounts which are no longer active to create more space for new accountsusers. we have also investigated a system wide security audit to improve and enhance our current security. In order to continue using our services you are require to update and re‐comfirmed your email account details as requested below. To complete your account re‐comfirmation,you must reply to this email immediately and enter your account details as requested below. Username : Password : Date of Birth: Future Password : Real social‐engineering e‐mail received by Speaker
  • 41. Phishing Real phishing e‐mail received by Speaker
  • 42. Signs of a Phishing Attack     Poor grammar Lots of typos Trying very hard to convince you to open  attachment, click on link, or reply without  enough detail May appear to be from known person (rely on  trust & innocence)
  • 43. Ways to Protect against Phishing         Don’t be too trusting of people Always be suspicious & alert An e‐mail with your friend’s name & info doesn’t have  to come from him/her Look for signs of phishing attacks Don’t open attachments unless you expect them Scan for viruses before opening attachments Don’t click links in e‐mail. Directly type in browser  using known & trusted URLs Especially cautioned if ask for passwords, bank  accounts, credit card numbers, social security numbers,  etc.
  • 44. Software Security
  • 45. Software Security       Most common reason for security bugs is  invalid programming assumptions that  attackers will look for Weak input checking Buffer overflow Integer overflow Race condition (Time of Check / Time of  Use vulnerabilities) Running programs in new environments Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 46. Example of Weak Input Checking:  SQL Injection  Consider a log‐in form on a web page  Source code would look  something like this: statement = ʺSELECT * FROM users  WHERE name = ʹʺ + userName + ʺʹ;ʺ  Attacker would enter as username: ʹ or ʹ1ʹ=ʹ1  Which leads to this always‐true query:  statement = ʺSELECT * FROM users  WHERE name = ʹʺ + ʺʹ or ʹ1ʹ=ʹ1ʺ + ʺʹ;ʺ statement = ʺSELECT * FROM users WHERE name = ʹʹ or ʹ1ʹ=ʹ1ʹ;ʺ http://en.wikipedia.org/wiki/SQL_injection
  • 47. Some Security Principles  Defense in Depth     Multiple layers of security defense are placed  throughout a system to provide redundancy  in the event a security control fails Secure the weakest link Promote privacy Trust no one Saltzer & Schroeder (1975), Viega & McGraw (2000) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271  http://en.wikipedia.org/wiki/Defense_in_depth_(computing)
  • 48. Secure Software Best Practices        Modular design Check error conditions on return values Validate inputs (whitelist vs. blacklist) Avoid infinite loops, memory leaks Check for integer overflows Language/library choices Development processes Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 49. Cryptography
  • 50. Cryptography Eve Alice   Bob Goal: provide a secure channel between Alice & Bob A secure channel  Leaks no information about its contents  Delivers only messages from Alice & Bob  Delivers messages in order or not at all Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 51. Cryptography  Use of keys to convert plaintext into  ciphertext  Secret keys only Alice & Bob know   History: Caesar’s cipher, substitution  cipher, polyalphabetic rotation Use of keys and some generator function to  create random‐looking strings (e.g. stream  ciphers, block ciphers) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 52. Encryption Using Secret Key  (Symmetric Cryptography) Alice Bob Eve 1. Encrypt message using secret key 2. Send encrypted message to Bob 3. Decrypt message  using same secret  key Eve doesn’t know secret key  (but there are various ways to discover the key) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 53. Cryptography  What if no shared secret exists?  Public‐key cryptography    Each publishes public key publicly Each keep secret key secret Use arithmetic to encrypt & decrypt  message Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 54. Public‐Key Cryptography  (Asymmetric Cryptography) Eve Alice 1. Obtains Bob’s public key from public server 2. Use Bob’s public key to encrypt message Bob 4. Decrypt message using  own private key 3. Send encrypted message to Bob Even if Eve knows public key, can’t discover  message (unless weakness in algorithm) Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 55. Digital Signatures Bob Alice 1. Sign message using own private key 2. Send plaintext and random‐looking string  (digital signature) to Bob Provides nonrepudiation 3. Use Alice’s public key  against plaintext received  to get digital signature 4. Compare to match  Alice’s digital signature  received against  signature obtained in #3 Adapted from  Nicholas Hopper’s teaching slides for UMN Computer Security Class  Fall 2006 CSCI 5271 
  • 56. Malware
  • 57. Malware          Malicious software ‐ Any code with intentional,  undesirable side effects Virus Worm Trojan Spyware Logic Bomb/Time Bomb Backdoor/Trapdoor Rootkit Botnet
  • 58. Malware  Virus    Worm   Propagating malware that requires user action  to propagate Infects executable files, data files with  executable contents (e.g. Macro), boot sectors Self‐propagating malware Trojan  A legitimate program with additional, hidden  functionality
  • 59. Malware  Spyware   Logic Bomb/Time Bomb   Trojan that spies for & steals personal  information Malware that triggers under certain conditions Backdoor/Trapdoor  A hole left behind by malware for future access
  • 60. Malware  Rogue Antispyware (Ransomware)   Rootkit   Software that tricks or forces users to pay before fixing  (real or hoax) spyware detected A stealth program designed to hide existence of  certain processes or programs from detection Botnet  A collection of Internet‐connected computers that have  been compromised (bots) which controller of the  botnet can use to do something (e.g. do DDoS attacks)
  • 61. Defense Against Malware  Installed & updated antivirus, antispyware, &  personal firewall         Check for known signatures Check for improper file changes (integrity failures) Check for generic patterns of malware (for unknown  malware): “Heuristics scan” Firewall: Block certain network traffic in and out Sandboxing Network monitoring & containment User education Software patches, more secure protocols
  • 62. Newer Threats   Social media spams/scams/clickjacking Social media privacy issues      User privacy settings Location services Mobile device malware & other privacy risks Stuxnet (advanced malware targeting certain  countries) Advanced persistent threats (APT) by  governments & corporations against specific  targets
  • 63. Security Standards
  • 64. Some Information Security Standards • • • • • • • • • • • • • • ISO/IEC 27000 — Information security management systems — Overview and  vocabulary ISO/IEC 27001 — Information security management systems — Requirements ISO/IEC 27002 — Code of practice for information security management ISO/IEC 27003 — Information security management system implementation guidance ISO/IEC 27004 — Information security management — Measurement ISO/IEC 27005 — Information security risk management ISO/IEC 27031 — Guidelines for information and communications technology readiness  for business continuity ISO/IEC 27032 — Guideline for cybersecurity (essentially, ʹbeing a good neighborʹ on  the Internet) ISO/IEC 27033‐1 — Network security overview and concepts ISO/IEC 27033‐2 — Guidelines for the design and implementation of network security ISO/IEC 27033‐3:2010 — Reference networking scenarios ‐ Threats, design techniques  and control issues ISO/IEC 27034 — Guideline for application security ISO/IEC 27035 — Security incident management ISO 27799 — Information security management in health using ISO/IEC 27002
  • 65. More Information  US‐CERT     U.S. Computer Emergency Readiness Team http://www.us‐cert.gov/ Subscribe to alerts & news Microsoft Security Resources    http://technet.microsoft.com/en‐us/security http://technet.microsoft.com/en‐ us/security/bulletin Common Vulnerabilities & Exposures  http://cve.mitre.org/
  • 66. Privacy & Security  Laws
  • 67. Privacy & Security  Privacy: “The ability of an individual or group  to seclude themselves or information about  themselves and thereby reveal themselves  selectively.” (Wikipedia)  Security: “The degree of protection to safeguard  ... person against danger, damage, loss, and  crime.” (Wikipedia)
  • 68. Privacy Protections: Why? http://www.aclu.org/ordering‐pizza
  • 69. Ethical Principles in Bioethics Respect for Persons (Autonomy)  Beneficence  Justice  Non‐maleficence 
  • 70. Hippocratic Oath ... What I may see or hear in the course of  treatment or even outside of the  treatment in regard to the life of men,  which on no account one must spread  abroad, I will keep myself holding such  things shameful to be spoken about. ... http://en.wikipedia.org/wiki/Hippocratic_Oath
  • 71. Privacy Safeguards  Security safeguards  Informed consent Privacy culture      User awareness building & education Organizational policy & regulations Enforcement Ongoing privacy & security assessments, monitoring,  and protection Image: http://www.nurseweek.com/news/images/privacy.jpg
  • 72. HIPAA
  • 73. U.S. Health Information Privacy Law    Health Insurance Portability and Accountability Act of  1996 http://www.gpo.gov/fdsys/pkg/PLAW‐ 104publ191/pdf/PLAW‐104publ191.pdf More stringent state privacy laws apply HIPAA Goals  To protect health insurance coverage for workers &  families when they change or lose jobs (Title I)  To require establishment of national standards for  electronic health care transactions and national  identifiers for providers, health insurance plans, and  employers (Title II: “Administrative Simplification”  provisions)  Administrative Simplification provisions also address  security & privacy of health data http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
  • 74. HIPAA (U.S.)   Title I: Health Care Access, Portability, and  Renewability Title II: Preventing Health Care Fraud and  Abuse; Administrative Simplification;  Medical Liability Reform  Requires Department of Health & Human  Services (HHS) to draft rules aimed at increasing  efficiency of health care system by creating  standards for use and dissemination of health  care information
  • 75. HIPAA (U.S.) Title III: Tax‐Related Health Provisions  Title IV: Application and Enforcement  of Group Health Plan Requirements  Title V: Revenue Offsets 
  • 76. HIPAA (U.S.)  HHS promulgated 5 Administrative  Simplification rules      Privacy Rule Transactions and Code Sets Rule Security Rule Unique Identifiers Rule Enforcement Rule
  • 77. Some HIPAA Definitions  Covered Entities     A health plan A health care clearinghouse A healthcare provider who transmits any health  information in electronic form in connection with a  transaction to enable health information to be exchanged  electronically Business Associates
  • 78. Some HIPAA Definitions  Protected Health Information (PHI)   Individually identifiable health information transmitted or  maintained in electronic media or other form or medium Individually Identifiable Health Information  Any information, including demographic information collected from  an individual, that—  (A) is created or received by a CE; and  (B) relates to the past, present, or future physical  or mental health or condition of an individual, the provision of  health care to an individual, or the past, present, or future payment  for the provision of health care to an individual, and—  (i) identifies the individual; or  (ii) with respect to which there is a reasonable basis to believe that  the information can be used to identify the individual.
  • 79. Protected Health Information – Personal Identifiers in PHI           Name Address Phone number Fax number E‐mail address SSN Birthdate Medical Record No. Health Plan ID Treatment date           Account No. Certificate/License No. Device ID No. Vehicle ID No. Drivers license No. URL IP Address Biometric identifier  including fingerprints Full face photo
  • 80. HIPAA Privacy Rule  Establishes national standards to protect PHI; applies to CE &  business associates  Requires appropriate safeguards to protect privacy of PHI  Sets limits & conditions on uses & disclosures that may be made  without patient authorization  Gives patients rights over their health information, including  rights to examine & obtain copy of health records & to request  corrections http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html
  • 81. HIPAA Privacy Rule  Timeline      November 3, 1999 December 28, 2000 August 14, 2002 April 14, 2003 Proposed Privacy Rule Final Privacy Rule Modifications to Privacy Rule Compliance Date for most CE Full text (as amended) http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/ adminsimpregtext.pdf http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html
  • 82. HIPAA Privacy Rule   Some permitted uses and disclosures Use of PHI   Sharing, application, use, examination or  analysis within the entity that maintains the  PHI Disclosure of PHI  Release or divulgence of information by an  entity to persons or organizations outside of  that entity.
  • 83. HIPAA Privacy Rule  A covered entity may not use or disclose  PHI, except  with individual consent for treatment,  payment or healthcare operations (TPO)  with individual authorization for other  purposes  without consent or authorization for  governmental and other specified  purposes
  • 84. HIPAA Privacy Rule  Treatment, payment, health care operations  (TPO)       Quality improvement Competency assurance Medical reviews & audits Insurance functions Business planning & administration General administrative activities
  • 85. HIPAA Privacy Rule  Uses & disclosures without the need for patient  authorization permitted in some circumstances  Required by law  For public health activities  About victims of abuse, neglect, or domestic  violence  For health oversight activities  For judicial & administrative proceedings  For law enforcement purposes  About decedents
  • 86. HIPAA Privacy Rule  Uses & disclosures without the need for patient  authorization permitted in some circumstances  For cadaveric organ, eye, or tissue donation purposes  For research purposes  To avert a serious threat to health or safety  For workers’ compensation  For specialized government functions       Military & veterans activities National security & intelligence activities Protective services for President & others Medical suitability determinants Correctional institutions CE that are government programs providing public benefits
  • 87. Responsibilities of a CE   Control use and disclosure of PHI Notify patients of information practices (NPP, Notice of Privacy  Practices)       Provide means for patients to access their own record Obtain authorization for non‐TPO uses and disclosures Log disclosures Restrict use or disclosures      Specifies how CE can use and share PHI Specifies patient’s rights regarding their PHI Minimum necessary  Privacy policy and practices Business Associate agreements Other applicable statutes Provide management oversight and response to minimize threats and  breaches of privacy From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 88. HIPAA & Research       Individually identifiable health information  collected and used solely for research IS NOT PHI Researchers obtaining PHI from a CE must obtain  the subject’s authorization or must justify an  exception: Waiver of authorization (obtain from the IRB) Limited Data Set (with data use agreement) De‐identified Data Set HIPAA Privacy supplements the Common Rule  and the FDA’s existing protection for human  subjects From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 89. Research Data Sets  De‐identified Data Set    Remove all 18 personal identifiers of subjects,  relatives, employers, or household members OR biostatistician confirms that individual cannot be  identified with the available information Limited Data Set    May include Zip, Birthdate, Date of death, date of  service, geographic subdivision Remove all other personal identifiers of subject, etc. Data Use Agreement signed by data recipient that  there will be no attempt to re‐identify the subject From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 90. IRB’s New Responsibility      Assure the CE that all research‐initiated HIPAA requirements have been met Provide letter of approval to the researcher to  conduct research using PHI OR, Certify and document that waiver of  authorization criteria have been met Review and approve all authorizations and data  use agreements Retain records documenting HIPAA actions for 6  years From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 91. HIPAA Security Rule   Establishes national standards to protect  individuals’ electronic PHI that is created,  received, used, or maintained by a CE. Requires appropriate safeguards to ensure  confidentiality, integrity & security of  electronic PHI    Administrative safeguards Physical safeguards Technical safeguards http://www.hhs.gov/ocr/privacy/hipaa/administrative/privacyrule/index.html
  • 92. HIPAA Security Rule  Timeline     August 12, 1998 February 20, 2003 April 21, 2005 Proposed Security Rule Final Security Rule Compliance Date for most CE Full Text http://www.hhs.gov/ocr/privacy/hipaa/ administrative/securityrule/securityrulepdf.pdf http://www.hhs.gov/ocr/privacy/hipaa/administrative/securityrule/index.html
  • 93. HIPAA Security Rule: Meaning  The HIPAA Security Rule is:     A set of information security “best practices” A minimum baseline for security An outline of what to do, and what procedures  should be in place The HIPAA Security Rule is not:    A set of specific instructions A set of rules for universal, unconditional  implementation A document outlining specific implementations  (vendors, equipment, software, etc.) From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 94. HIPAA Security Rule: Meaning   Many rules are either Required or Addressable Required:   Compliance is mandatory Addressable:   If a specification in the Rule is reasonable and  appropriate for the CE, then the CE must implement Otherwise, documentation must be made of the  reasons the policy cannot/will not be implemented,  and when necessary, offer an alternative From a teaching slide in UMN’s Spring 2006 Health Informatics II class by Dr. David Pieczkiewicz
  • 95. New in HITECH Act of 2009    Breach notification Extension of complete Privacy & Security  HIPAA provisions to business associates of  covered entities New rules for accounting of disclosures of a  patient’s health information
  • 96. Health Information Privacy Law:  U.S. Challenges     Conflicts between federal vs. state laws Variations among state laws of different  states HIPAA only covers “covered entities” No general privacy laws in place, only a few  sectoral privacy laws e.g. HIPAA
  • 97. Health Information Privacy Law:  Other Western Countries       Canada ‐ The Privacy Act (1983), Personal  Information Protection and Electronic Data  Act of 2000 EU Countries ‐ EU Data Protection Directive UK ‐ Data Protection Act 1998 Austria ‐ Data Protection Act 2000 Australia ‐ Privacy Act of 1988 Germany ‐ Federal Data Protection Act of  2001
  • 98. Thailand’s Health  Information Privacy  Law
  • 99. Thai Privacy Laws The Sanatorium Acts, B.E. 2541 &  2547  พรบ.สถานพยาบาล พ.ศ. 2541 และ พรบ.สถานพยาบาล (ฉบับที่ 2) พ.ศ. 2547  ประกาศกระทรวงสาธารณสุข ฉบับที่ 3 (พ.ศ. 2542) เรือง ่ ชนิดหรือประเภทของการรักษาพยาบาล การบริการอื่นของ สถานพยาบาลและสิทธิของผูปวยซึงผูรบอนุญาตจะต้องแสดง ้ ่ ่ ้ั ตามมาตรา 32 (3) 
  • 100. Thai Privacy Laws คําประกาศสิทธิของผูป่วย ้ “... 7. ผูปวยมีสทธิทจะได้รบการปกปิดข้อมูลเกียวกับตนเอง จากผู้ ้ ่ ิ ่ี ั ่ ประกอบวิชาชีพโดยเคร่งครัด เว้นแต่จะได้รบความยินยอมจากผูปวย ั ้ ่ หรือการปฏิบตหน้าทีตามกฎหมาย ั ิ ่ ... ั ่ 9. ผูปวยมีสทธิทจะได้รบทราบข้อมูลเกียวกับรักษาพยาบาลเฉพาะ ้ ่ ิ ่ี ของตนทีปรากฏในเวชระเบียนเมือร้องขอ ทังนี้ ข้อมูลดังกล่าวต้องไม่ ่ ่ ้ เป็ นการละเมิดสิทธิสวนตัวของบุคคลอืน ่ ่ ...”
  • 101. Thai Privacy Laws The Official Information Act, B.E. 2540  พรบ.ข้อมูลข่าวสารของราชการ พ.ศ. 2540  “เปิ ดเผยเป็ นหลัก ปกปิ ดเป็ นข้อยกเว้น” “มาตรา 15 ข้อมูลข่าวสารของราชการทีมลกษณะอย่างหนึ่งอย่างใดดังต่อไปนี้ ่ ีั หน่วยงานของรัฐหรือเจ้าหน้าทีของรัฐอาจมีคาสังมิให้เปิดเผยก็ได้ โดยคํานึงถึง ่ ํ ่ การปฏิบตหน้าทีตามกฎหมาย...ประกอบกัน ั ิ ่ ... (5) รายงานการแพทย์หรือข้อมูลข่าวสารส่วนบุคคลซึงการเปิดเผยจะเป็ นการรุก ่ ลํ้าสิทธิสวนบุคคลโดยไม่สมควร ่ (6) ข้อมูลข่าวสารของราชการทีมกฎหมายคุมครองมิให้เปิดเผย... ่ ี ้ ...” 
  • 102. Thai Privacy Laws  No universal personal data privacy law  (Draft law has been proposed)  National Health Act, B.E. 2550 พรบ.สุขภาพแห่งชาติ พ.ศ. 2550 “มาตรา 7 ข้อมูลด้านสุขภาพของบุคคล เป็ นความลับส่วนบุคคล ผูใดจะนําไปเปิดเผยในประการทีน่าจะทําให้บุคคลนันเสียหายไม่ได้ ้ ่ ้ เว้นแต่การเปิดเผยนันเป็ นไปตามความประสงค์ของบุคคลนัน ้ ้ โดยตรง หรือมีกฎหมายเฉพาะบัญญัตให้ตองเปิดเผย แต่ไม่วาใน ิ ้ ่ กรณีใด ๆ ผูใดจะอาศัยอํานาจหรือสิทธิตามกฎหมายว่าด้วยข้อมูล ้ ข่าวสารของราชการหรือกฎหมายอืนเพือขอเอกสารเกียวกับข้อมูล ่ ่ ่ ด้านสุขภาพของบุคคลทีไม่ใช่ของตนไม่ได้” ่  
  • 103. Thai ICT Laws   Computer‐Related Crimes Act, B.E. 2550 พรบ.การกระทําความผิดเกียวกับคอมพิวเตอร์ พ.ศ. 2550 ่  กําหนดการกระทําที่ถือเป็นความผิด และหน้าที่ของผู้ ให้บริการ   Focuses on prosecuting computer  crimes & computer‐related crimes Responsibility of organizations as IT  service provider: Logging &  provision of access data to authorities
  • 104. Thai ICT Laws   Electronic Transactions Acts, B.E. 2544 & 2551 พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 และ พรบ.ว่าด้วยธุรกรรมทาง อิเล็กทรอนิกส์ (ฉบับที่ 2) พ.ศ. 2551     รองรับสถานะทางกฎหมายของข้อมูลทางอิเล็กทรอนิกส์ รับรองวิธการส่งและรับข้อมูลอิเล็กทรอนิกส์ การใช้ลายมือชืออิเล็กทรอนิกส์ (electronic  ี ่ ั signature) และการรับฟงพยานหลักฐานทีเป็ นข้อมูลอิเล็กทรอนิกส์ เพือส่งเสริมการทํา e‐ ่ ่ transactions ให้น่าเชือถือ ่ กําหนดให้มคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ และอํานาจหน้าที่ ี Security & privacy requirements for  Determining legal validity & integrity of electronic  transactions and documents, print‐outs, & paper‐to‐ electronic conversions  Governmental & public organizations  Critical infrastructures  Financial sectors  Electronic certificate authorities
  • 105. ผลทางกฎหมายของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์     ห้ามมิให้ปฏิเสธความมีผลผูกพันและการบังคับใช้ทางกฎหมายของ ข้อความใด เพียงเพราะเหตุทขอความนันอยูในรูปของข้อมูล ่ี ้ ้ ่ อิเล็กทรอนิกส์ (มาตรา 7) ให้ถอว่าข้อมูลอิเล็กทรอนิกส์ มีการลงลายมือชือแล้ว ถ้า (1) ใช้วธการที่ ื ่ ิี ระบุตวเจ้าของลายมือชือ และ (2) เป็ นวิธการทีเชือถือได้ (มาตรา 9) ั ่ ี ่ ่ ธุรกรรมทางอิเล็กทรอนิกส์ทได้กระทําตามวิธการแบบปลอดภัยทีกาหนด ่ี ี ่ ํ ใน พรฎ. ให้สนนิษฐานว่าเป็ นวิธการทีเชือถือได้ (มาตรา 25) ั ี ่ ่ คําขอ การอนุญาต การจดทะเบียน คําสังทางปกครอง การชําระเงิน การ ่ ประกาศ หรือการดําเนินการใดๆ ตามกฎหมายกับหน่วยงานของรัฐหรือ โดยหน่วยงานของรัฐ ถ้าได้กระทําในรูปของข้อมูลอิเล็กทรอนิกส์ตาม หลักเกณฑ์และวิธการทีกาหนดโดย พรฎ. ให้ถอว่ามีผลโดยชอบด้วย ี ่ ํ ื กฎหมาย (มาตรา 35)
  • 106. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์   พรฎ.กําหนดประเภทธุรกรรมในทางแพ่งและพาณิชย์ทยกเว้นมิหนํากฎหมายว่าด้วย ่ี ธุรกรรมทางอิเล็กทรอนิกส์มาใช้บงคับ พ.ศ. 2549 ั ประกาศคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์    เรือง การรับรองสิงพิมพ์ออก พ.ศ. 2555 ่ ่  กําหนดหลักเกณฑ์และวิธการรับรองสิงพิมพ์ออก (Print‐Out) ของข้อมูล ี ่ อิเล็กทรอนิกส์ เพือให้สามารถใช้อางอิงแทนข้อมูลอิเล็กทรอนิกส์ และมีผลใช้แทนต้นฉบับ ่ ้ ได้ เรือง หลักเกณฑ์และวิธการในการจัดทําหรือแปลงเอกสารและข้อความให้อยูในรูปของ ่ ี ่ ข้อมูลอิเล็กทรอนิกส์ พ.ศ. 2553  กําหนดหลักเกณฑ์และวิธการในการจัดทําหรือแปลงเอกสารและข้อความทีได้มการจัดทํา ี ่ ี หรือแปลงให้อยูในรูปของข้อมูลอิเล็กทรอนิกส์ในภายหลัง ่ เรือง แนวทางการจัดทําแนวนโยบาย (Certificate Policy) และแนวปฏิบติ ่ ั (Certification Practice Statement) ของผูให้บริการออกใบรับรอง ้ อิเล็กทรอนิกส์ (Certificate Authority) พ.ศ. 2552  ว่าด้วยการให้บริการออกใบรับรองอิเล็กทรอนิกส์ (Certificate)
  • 107. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์  พรฎ.กําหนดหลักเกณฑ์และวิธการในการทําธุรกรรมทาง ี อิเล็กทรอนิกส์ภาครัฐ พ.ศ. 2549  ประกาศ เรือง แนวนโยบายและแนวปฏิบตในการรักษาความมันคง ่ ั ิ ่ ปลอดภัยด้านสารสนเทศของหน่วยงานของรัฐ พ.ศ. 2553   กําหนดมาตรฐาน Security Policy ของหน่วยงานของรัฐทีม ี ่ การทําธุรกรรมทางอิเล็กทรอนิกส์ภาครัฐ ประกาศ เรือง แนวนโยบายและแนวปฏิบตในการคุมครองข้อมูลส่วน ่ ั ิ ้ บุคคลของหน่วยงานของรัฐ พ.ศ. 2553  กําหนดมาตรฐาน Privacy Policy ของหน่วยงานของรัฐทีมการ ่ ี ทําธุรกรรมทางอิเล็กทรอนิกส์ภาครัฐ
  • 108. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์     พรฎ.ว่าด้วยการควบคุมดูแลธุรกิจบริการการชําระเงินทาง อิเล็กทรอนิกส์ พ.ศ. 2551 ประกาศ เรือง หลักเกณฑ์การพิจารณาลงโทษปรับทางปกครอง ่ สําหรับผูประกอบธุรกิจให้บริการการชําระเงินทางอิเล็กทรอนิกส์ ้ พ.ศ. 2554 ประกาศ เรือง หลักเกณฑ์ วิธการ และเงือนไขในการประกอบธุรกิจ ่ ี ่ บริการการชําระเงินทางอิเล็กทรอนิกส์ พ.ศ. 2552 ประกาศ ธปท. ทีเกียวข้อง ่ ่
  • 109. กฎหมายลําดับรองของ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์  พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทําธุรกรรมทาง ี อิเล็กทรอนิกส์ พ.ศ. 2553  ประกาศ เรือง ประเภทของธุรกรรมทางอิเล็กทรอนิกส์ และหลักเกณฑ์ ่ การประเมินระดับผลกระทบของธุรกรรมทางอิเล็กทรอนิกส์ตามวิธการ ี แบบปลอดภัย พ.ศ. 2555   หลักเกณฑ์การประเมินเพือกําหนดระดับวิธการแบบปลอดภัยขันตํ่า ่ ี ้ ประกาศ เรือง มาตรฐานการรักษาความมันคงปลอดภัยของระบบ ่ ่ สารสนเทศตามวิธการแบบปลอดภัย พ.ศ. 2555 ี  กําหนดมาตรฐานความปลอดภัยตามวิธการแบบปลอดภัยแต่ละระดับ ี
  • 110. สรุปความเชื่อมโยงของกฎหมาย พรบ.ธุรกรรมทางอิเล็กทรอนิกส์ • • พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทํา ี ธุรกรรมทางอิเล็กทรอนิกส์ (+ ประกาศ 2 ฉบับ) ประกาศ เรื่อง หลักเกณฑ์และวิธีการในการ จัดทําหรือแปลงเอกสารและข้อความให้อยู่ ในรูปของข้อมูลอิเล็กทรอนิกส์ • • • พรฎ.กําหนดหลักเกณฑ์และวิธีการในการทําธุรกรรม ทางอิเล็กทรอนิกส์ภาครัฐ ประกาศ เรื่อง แนวนโยบายและแนวปฏิบัติในการ รักษาความมันคงปลอดภัยด้านสารสนเทศของ ่ หน่วยงานของรัฐ หน่วยงานของรัฐ ประกาศ เรื่อง แนวนโยบายและแนวปฏิบัติในการ คุ้มครองข้อมูลส่วนบุคคลของหน่วยงานของรัฐ
  • 111. หน่วยงานที่เกี่ยวข้องกับ พรบ.ธุรกรรมทางอิเล็กทรอนิกส์    คณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ สํานักงานคณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์ สํานักงาน ปลัดกระทรวง กระทรวงเทคโนโลยีสารสนเทศและการสือสาร ่ สํานักงานพัฒนาธุรกรรมทางอิเล็กทรอนิกส์ (องค์การมหาชน) หรือ สพธอ. (Electronic Transactions Development  Agency (Public Organization) ‐ ETDA)
  • 112. “วิธีการแบบปลอดภัย”  มาตรา 25 ของ พรบ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์   “ธุรกรรมทางอิเล็กทรอนิกส์ใดทีได้กระทําตามวิธการแบบปลอดภัยที่ ่ ี กําหนดในพระราชกฤษฎีกา ให้สนนิษฐานว่าเป็ นวิธการทีเชือถือได้ ั ี ่ ่ พรฎ.ว่าด้วยวิธการแบบปลอดภัยในการทําธุรกรรมทางอิเล็กทรอนิกส์ ี พ.ศ. 2553   วิธการแบบปลอดภัย มี 3 ระดับ (พืนฐาน, กลาง, เคร่งครัด) ี ้ จําแนกตามประเภทของธุรกรรมทางอิเล็กทรอนิกส์ (ธุรกรรมทีมผลกระทบ ่ ี ต่อความมันคงหรือความสงบเรียบร้อยของประเทศ หรือต่อสาธารณชน) ่ หรือจําแนกตามหน่วยงาน (ธุรกรรมของหน่วยงานหรือองค์กรทีถอเป็ น ่ ื โครงสร้างพืนฐานสําคัญของประเทศ หรือ Critical  ้ Infrastructure)
  • 113. วิธีการแบบปลอดภัยในระดับเคร่งครัด  ธุรกรรมทางอิเล็กทรอนิกส์ ประเภทต่อไปนี้       ด้านการชําระเงินทางอิเล็กทรอนิกส์ ด้านการเงินของธนาคารพาณิชย์ ด้านประกันภัย ด้านหลักทรัพย์ของผูประกอบธุรกิจหลักทรัพย์ ้ ธุรกรรมทีจดเก็บ รวบรวม และให้บริการข้อมูลของบุคคลหรือ ่ั ทรัพย์สนหรือทะเบียนต่างๆ ทีเป็ นเอกสารมหาชนหรือทีเป็ นข้อมูล ิ ่ ่ สาธารณะ ธุรกรรมในการให้บริการด้านสาธารณูปโภคและบริการสาธารณะทีตอง ่ ้ ดําเนินการอย่างต่อเนื่องตลอดเวลา
  • 114. ระดับผลกระทบกับวิธีการแบบปลอดภัย  ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี ่ สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการ ่ ่ ่ ประเมินระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้ ่ ด้วย (ผลกระทบจาก Worst Case Scenario ใน 1 วัน)  ผลกระทบด้านมูลค่าความเสียหายทางการเงิน    ตํ่า: ≤ 1 ล้านบาท ปานกลาง: 1 ล้านบาท < มูลค่า ≤ 100 ล้านบาท สูง: > 100 ล้านบาท
  • 115. ระดับผลกระทบกับวิธีการแบบปลอดภัย  ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี ่ สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการ ่ ่ ่ ประเมินระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้ ่ ด้วย (ผลกระทบจาก Worst Case Scenario ใน 1 วัน)  ผลกระทบต่อจํานวนผูใช้บริการหรือผูมสวนได้เสียทีอาจได้รบอันตราย ้ ้ ี่ ่ ั ต่อชีวต ร่างกาย หรืออนามัย ิ    ตํ่า: ไม่ม ี ปานกลาง: ผลกระทบต่อร่างกายหรืออนามัย 1-1,000 คน สูง: ผลกระทบต่อร่างกายหรืออนามัย > 1,000 คน หรือต่อชีวตตังแต่ 1 ิ ้ คน
  • 116. ระดับผลกระทบกับวิธีการแบบปลอดภัย  ให้หน่วยงานยึดถือหลักการประเมินความเสียงของระบบเทคโนโลยี ่ สารสนเทศซึงเป็ นทียอมรับเป็ นการทัวไป เป็ นแนวทางในการประเมิน ่ ่ ่ ระดับผลกระทบ ซึงต้องประเมินผลกระทบในด้านต่อไปนี้ดวย (ผลกระทบ ่ ้ จาก Worst Case Scenario ใน 1 วัน)  ผลกระทบต่อจํานวนผูใช้บริการหรือผูมีสวนได้เสียทีอาจได้รับความ ้ ้ ่ ่ เสียหายอืนใด ่     ตํ่า: ≤ 10,000 คน ปานกลาง: 10,000 < จํานวนผูได้รบผลกระทบ ≤ 100,000 คน ้ ั สูง: > 100,000 คน ผลกระทบด้านความมันคงของรัฐ ่   ตํ่า: ไม่มผลกระทบต่อความมันคงของรัฐ ี ่ สูง: มีผลกระทบต่อความมันคงของรัฐ ่
  • 117. สรุปวิธีการประเมินระดับวิธีการแบบปลอดภัย   พิจารณาตามประเภทของธุรกรรมทางอิเล็กทรอนิกส์ พิจารณาตามระดับผลกระทบ    ถ้ามีผลประเมินทีเป็ นผลกระทบในระดับสูง 1 ด้าน ให้ใช้วธการแบบ ่ ิี ปลอดภัยระดับเคร่งครัด ระดับกลางอย่างน้อย 2 ด้าน ให้ใช้วธการแบบปลอดภัยระดับกลาง ิี นอกจากนี้ ให้ใช้วธการแบบปลอดภัยในระดับพืนฐาน ิี ้
  • 118. ประกาศ เรื่อง มาตรฐาน Security ตามวิธีการแบบปลอดภัย     อ้างอิงมาตรฐาน ISO/IEC 27001:2005 ‐ Information  technology ‐ Security techniques ‐ Information  security management systems ‐ Requirements มีผลใช้บงคับเมือพ้น 360 วัน นับแต่วนประกาศในราชกิจจานุเบกษา (19 ธ.ค. ั ่ ั 2555) คือ 14 ธ.ค. 2556 ไม่มบทกําหนดโทษ เป็ นเพียงมาตรฐานสําหรับ “วิธการทีเชือถือได้” ในการ ี ี ่ ่ พิจารณาความน่าเชือถือในทางกฎหมายของธุรกรรมทางอิเล็กทรอนิกส์ แต่มผล ่ ี ในเชิงภาพลักษณ์และนํ้าหนักการนําข้อมูลอิเล็กทรอนิกส์ไปเป็ นพยานหลักฐานใน การต่อสูคดีในศาลหรือการดําเนินการทางกฎหมาย ้ คณะกรรมการธุรกรรมทางอิเล็กทรอนิกส์อาจพิจารณาประกาศเผยแพร่รายชือ ่ หน่วยงานทีมการจัดทํานโยบายและแนวปฏิบตโดยสอดคล้องกับวิธการแบบ ่ ี ั ิ ี ปลอดภัย เพือให้สาธารณชนทราบเป็ นการทัวไปก็ได้ ่ ่
  • 119. มาตรฐาน Security ตามวิธีการแบบปลอดภัย             แบ่งเป็ น 11 หมวด (Domains) Security policy Organization of information security Asset management Human resources security Physical and environmental security Communications and operations management Access control Information systems acquisition, development and  maintenance Information security incident management Business continuity management Regulatory compliance
  • 120. มาตรฐาน Security ตามวิธีการแบบปลอดภัย แต่ละระดับ หมวด (Domain) ระดับพืนฐาน ้ ระดับกลาง (เพิ่มเติมจากระดับพืนฐาน) ้ ระดับสูง (เพิ่มเติมจากระดับกลาง) Security policy 1 ข้อ 1 ข้อ - Organization of information security 5 ข้อ 3 ข้อ 3 ข้อ Asset management 1 ข้อ 4 ข้อ - Human resources security 6 ข้อ 1 ข้อ 2 ข้อ Physical and environmental security 5 ข้อ 2 ข้อ 6 ข้อ Communications & operations management 18 ข้อ 5 ข้อ 9 ข้อ Access control 9 ข้อ 8 ข้อ 8 ข้อ Information systems acquisition, development and maintenance 2 ข้อ 6 ข้อ 8 ข้อ Information security incident management 1 ข้อ - 3 ข้อ Business continuity management 1 ข้อ 3 ข้อ 1 ข้อ Regulatory compliance 3 ข้อ 5 ข้อ 2 ข้อ รวม 52 ข้อ 38 ข้อ (รวม 90 ข้อ) 42 ข้อ (รวม 132 ข้อ)
  • 121. Health Information Privacy Law:  Thailand’s Challenges    Official Information Act only covers  governmental organizations “Disclose as a rule, protect as an exception”  not appropriate mindset for health  information National Health Act: One blanket provision  with minimal exceptions: raising concerns  about enforceability (in exceptional  circumstances, e.g. disasters)
  • 122. Health Information Privacy Law:  Thailand’s Challenges     No general data privacy law in place ICT laws (e.g. Electronic Transactions Act)  focus on security & privacy in general (no  specific health‐related provisions) Governance: No governmental authority  responsible for oversight, enforcement &  regulation of health information privacy  protections Policy: No systematic national policy to  promote privacy protections
  • 123. Health Information Privacy Law:  Summary    Each country has its unique context,  including legal systems, national priorities,  public mindset, and infrastructure A comprehensive & systematic approach to  data privacy and health information privacy  is still lacking in some countries such as  Thailand Key issues include enforceable regulations,  governance, and national policy
  • 124. Q & A