Difference between revisions of "Healthcare Code of Conduct"
From MgmtWiki
(→Context) |
(→Norwegian) |
||
(9 intermediate revisions by the same user not shown) | |||
Line 11: | Line 11: | ||
===Norwegian=== | ===Norwegian=== | ||
+ | * There are two categories, large and small organizations. The small guys get series of passes. | ||
+ | * There are a series of fact sheets as summarized below. These all include something that looks like assessment criteria except for the first. | ||
+ | ** the actors in a healthcare covered entity. | ||
+ | ** There shall be a security management system where PHI is present. | ||
+ | ** Procedures must be inlace before processing PHI. | ||
+ | ** Security Audits shall be conducted at least annually. | ||
+ | ** Risk assessments must be carried out prior to operations, including any change that may impact security. | ||
+ | ** External data processors must agree to follow and report on compliance with regulations. | ||
+ | ** Access control appears to be granted based on the purpose of access. It seems to be up to each organization to create the purposes or roles. (RBAC?) | ||
+ | ** Incident registration and followup shall be inlace before PHI is collected and patient shall have access. Notice does not appear to be required. | ||
+ | ** Message communications are subject to national standards - which might be HL7 formats. not clear. It is called ebXML (which goes back to ANSI X12 EDI) and utilized a national ID. | ||
+ | ** Agreeing to research | ||
+ | ** Remote Acces to suppliers must respect confidentiality and integrity, etc. | ||
+ | ** Security seems to be homegrown. No international standards. | ||
+ | ** Infosec in research. | ||
+ | ** If PHI is accidentally disclose, try to limit the damage and stop any continuing release of PHI. | ||
+ | ** Test data seems to imply that real data is used and then destroyed. No indication if test data will be created that is not from live patients. | ||
+ | ** Register of authorizations sound like an RBAC registry that also logs access and roles by user. Somehow this data is to be compared with other registries to create security incidents. | ||
+ | ** Testing is agains describe as though real data is used in testing rather than dummy data. | ||
+ | ** PKI is assumed in use for signing, authentication and encryption. | ||
+ | ** Patient access to incident register. There are held by the data controller. It is not clear where the patient needs to go to access these registers. | ||
==References== | ==References== |
Latest revision as of 16:37, 3 August 2021
Full Title or Meme
In Healthcare Identity Management a Code of Conduct applies to those software elements that handle the Patient Health Information.
Context
- See the wiki page Health Care Digital Identity for more about the context of this topic.
Examples
CARIN
Norwegian
- There are two categories, large and small organizations. The small guys get series of passes.
- There are a series of fact sheets as summarized below. These all include something that looks like assessment criteria except for the first.
- the actors in a healthcare covered entity.
- There shall be a security management system where PHI is present.
- Procedures must be inlace before processing PHI.
- Security Audits shall be conducted at least annually.
- Risk assessments must be carried out prior to operations, including any change that may impact security.
- External data processors must agree to follow and report on compliance with regulations.
- Access control appears to be granted based on the purpose of access. It seems to be up to each organization to create the purposes or roles. (RBAC?)
- Incident registration and followup shall be inlace before PHI is collected and patient shall have access. Notice does not appear to be required.
- Message communications are subject to national standards - which might be HL7 formats. not clear. It is called ebXML (which goes back to ANSI X12 EDI) and utilized a national ID.
- Agreeing to research
- Remote Acces to suppliers must respect confidentiality and integrity, etc.
- Security seems to be homegrown. No international standards.
- Infosec in research.
- If PHI is accidentally disclose, try to limit the damage and stop any continuing release of PHI.
- Test data seems to imply that real data is used and then destroyed. No indication if test data will be created that is not from live patients.
- Register of authorizations sound like an RBAC registry that also logs access and roles by user. Somehow this data is to be compared with other registries to create security incidents.
- Testing is agains describe as though real data is used in testing rather than dummy data.
- PKI is assumed in use for signing, authentication and encryption.
- Patient access to incident register. There are held by the data controller. It is not clear where the patient needs to go to access these registers.
References
- See the wiki page CARIN App Registration for details on one use case for the CARIN code of conduct.