HIPAA De-identification is one of the requirements to be considered for CCHIT Certification..
The details of it and the way to implement this in OpenEMR are explained below based on our limited understanding. At this point and based on our analysis, we feel that this needs to be taken care at the OpenEMR side..
Do let us know your views here.
HIPAA De-identification of Patient Health information (PHI) refers to the patients health informations
excluding the information identifying the patient uniquely. (or) It is the process of removing the
identification information from PHI (eg: name, address, contact numbers etc).
The De-identified Patient Health information (PHI) is used for various research, census and other
activities.
According to HIPAA, the de-identified PHI can be obtained by the exclusion of 18 specified
identifiers, which are as follows
1.Names;
2.All geographic subdivisions smaller than a State, including street address, city, county, precinct,
zip code, and their equivalent geocodes, except for the initial three digits of a zip code if,
according to the current publicly available data from the Bureau of the Census:
1.The geographic unit formed by combining all zip codes with the same three initial digits
contains more than 20,000 people; and
2.The initial three digits of a zip code for all such geographic units containing 20,000 or
fewer people is changed to 000.
3.Currently, 036, 059, 063, 102, 203, 556, 592, 790, 821, 823, 830, 831, 878, 879, 884,
890, and 893 are all recorded as "000".
3.All elements of dates (except year) for dates directly related to an individual, including birth
date, admission date, discharge date, date of death; and all ages over 89 and all elements of
dates (including year) indicative of such age, except that such ages and elements may be
aggregated into a single category of age 90 or older;
4.Telephone numbers;
5.Fax numbers;
6.Electronic mail addresses;
7.Social security numbers;
8.Medical record numbers;
9.Health plan beneficiary numbers;
10.Account numbers;
11.Certificate/license numbers;
12.Vehicle identifiers and serial numbers, including license plate numbers;
13.Device identifiers and serial numbers;
14.Web Universal Resource Locator's (URLs);
15.Internet Protocol (IP) address numbers;
16.Biometric identifiers, including finger and voice prints;
17.Full face photographic images and any comparable images; and
18.Any other unique identifying number, characteristic, or code (except as permitted by the reidentification
rules)
The different componets involved here are:
1. Study investigator- who needs the de-identified data for research purposes
2. Central authority (can be HIE/ Public Record Office) – authority who handles the requests for de-identified data from study investigator.
3. Hospitals/Physician practices - which provides De-identitified PHI (database)
The different steps carried out are:
1. Study investigator requests for de-identified PHI data to the central authority.
2. Central authority processes the request and send the request to various medical centers (hospital/physician practices).
3. A medical center on receiving request from central authority, de-identifies the PHI requested and sends the de-identified data to the central authority. (after it is reviewed by the QA team of the same medical center)
4. Central authority receives de-identified data from various medical centers.
5. Central authority holds/stores the origin of the information ( de-identified data) and return the same to the study investigator
On a broader perspective, the Patient Health Information (PHI) can be divided into,
Structured Data - Defines some finite data (like blood pressure, diagnosis etc)
Unstructured Data - Data in free text format like patient notes, progress notes etc
Based on the deidentification request, the admin (special user) inputs for the required details through a specialized GUI.
(Ex. The data can be retrieved only for a particular diagnosis)
The de-identified data is created using the following algorithm (only the high level logic is given):
1 For each resultant data, a unique reidentification code can be created
2. All the resultant data are processed one by one
a. For all the structured data, if the field is a unique identifier, it is removed directly
b. For the unstructured data, "lexical analysis" is made and if the unique identifier is present in that, it is ignored.
For example, "Joe London has cancer since 5 years" is one of the unstructed data, "Joe London" is removed (and can be replaced by 'xxxx') since this is one of the values for the unique identifier.
The resultant data can be provided as a report and will have the option to convert that as PDF
Do share your views here.
Thanks
ViCarePlus Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure that it's that simple or even possible to remove all identifiers from unstructured data. As per your example, one time the patient might be listed as "Joe London", another time as "Joseph London", another time as "Joe", another time "Joseph", a third time as "Mr London", a fourth time as "Joey Landon" (misspelled). It's relatively easy to remove the first and last name from structured data but I can't see any easy way to recognize all the names in unstructured data.
You may even have a line, "The patient is here with his daughter, Lucretia London-Borgia, who now has his health care proxy."
- Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The success of de-identification for unstructed data depends on data that is present/loaded into lexical look up table.
Suggestions for what data to be loaded into lexical look up table:
• Known names of patients and hospital staff and other elements specified by HIPAA not be included in de-identified data. (from the openemr database)
• Generic female and male first names, last names, last name prefixes, hospital names, locations and states which can be obtained from other external sources eg:census list etc. (we can provide options to admin to upload these kinds of list to lexical look up table - but not sure whether we can consider this for this phase)
• Design some regular expressions to identify URL's, date, person names etc.
(Eg: name indicators/titles like “Mr. “, “Dr.”, “Ms.” are found, can identify it as name), when a string matches the regular expression it can be ignored.
Do share your views here.
Thanks
ViCarePlus Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This raises the desirability of creating a flexible general-purpose data extraction tool, which might output either a spreadsheet-friendly file, or a "nice" database with a structure that is friendly to report generators. De-identification could then be added to this as an option with relative ease.
Please keep in touch with me about that as I may be asked to do some work in this area soon (without the de-identification).
Hi.
You have clearly given this a lot of thought, but I still question whether it is possible to effectively de-identify unstructured data. Here are some examples of unstructured data:
" The SEC and FBI have brought an indictment against Raj Rajanatram of Galleon Partners. The key witness is Roomy Khan, who is accused of passing confiidential data about AMD and Intel to Galleon."
"Sponsors have cut back on their ads featuring Tiger Woods."
"Mrs. Colon was found to have Dukes' B colon cancer. Her CEA level is 1.2 and she is scheduled for a CAT scan next week at Presbyterian Hospital in NYC."
To say nothing of the fact that I have a Bangladeshi patient whose first name is "Md", no vowels.
And what happens when someone types in all lower case by accident or laziness? You might be able to pull "Tiger Woods" out of a sentence but it's harder to remove "tiger" or "woods" in lower case, since they are both English words.
Don't you think it would just be better not to export any unstructured data? The adverse consequences of releasing protected health information are so great that it might be better not to risk it.
Thank you for considering my comments.
- Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The benefit of a data extraction tool is to gather data in a form that is suitable for import into a spreadsheet, or use by a general-purpose reporting tool like Jasper or Crystal Reports.
However I'm a month or more away from doing that, so don't let me hold you up.
De-Identification (at least for certification purposes) only applies to reports, such as the reports that might be transmitted to immunization registries. It does not apply to free text.
To pass certification we only need to de-identify reports.
Hope this helps
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for sharing your views on HIPAA de-identification.
You'd mentioned previously that we need not concentrate on unstructured data for HIPAA De-identification. Can you provide some links to that (if you've any) so that we can preserve the same for our future reference.
In your later mail, the meaningful objectives what you've mentioned as optional applies to HIPAA de-identification??
Thanks for your help here.
Thanks
ViCarePlus Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FOUNDATIONAL INFRASTRUCTURE: Security and Privacy (MU.P5.G1)
All test steps must be demonstrated. The applicant explicitly attests to the veracity of the features and functions demonstrated, the information furnished, and the statements made during the course of this inspection.
Exception: Test steps that are optional are highlighted in yellow. These steps are to be demonstrated if possible, but will not affect certification results.
Procedure Expected Result Criteria and Reference Vendor/Juror Guidance
FND.01 Demonstrate and describe how the technology provides the capability to allow access only to those persons or software programs that have been granted access rights. The capability is demonstrated. AR.FND 01.01 Provide capability to allow access only to those persons or software programs that have been granted access rights. The applicant must describe and demonstrate:
1. The ability to provide access only to authenticated users
2. The authentication procedure (e.g. account creation including user IDs, assignment of privileges,
3. The access control method, user-based, RBAC, SSO, EUA, SAML, context-based, etc.
4. The product’s password strength rule and password security (age, reuse, display, encryption, etc.)
5. The product’s limit of number of consecutive invalid attempt
6. The product’s Account lockout after exceeding the limit of number of invalid attempt:
- configurable time delay until next login
attempt
- require release by administrator
7. The ability to suspend user accounts
8. The history of inactive accounts
9. The ability to configure and display notice of warning against unauthorized use
10. The ability to generate audit record for valid logins and invalid login attempts
FND.02 Demonstrate and describe how the technology provides the capability to assign a unique name and/or number for identifying and tracking user identity. The capability is demonstrated. AR.FND 01.02 Provide capability to assign a unique name and/or number for identifying and tracking user identity. The applicant must describe and demonstrate:
1. Uniqueness of user IDs
2. Composition of user IDs
3. Case sensitivity and case insensitivity of user IDs
4. The ability to track user IDs in audit records
5. The ability to generate audit records for valid logins and invalid login attempts with user IDs
FND.03 Demonstrate and describe how the technology provides the capability to access necessary electronic protected health information during an emergency. The capability is demonstrated. AR.FND 01.03 Provide capability to access necessary electronic protected health information during an emergency. The applicant must describe and demonstrate:
1. The support for emergency access policies
2. The method supported for clinical user access in emergency situations also known as the break-the-glass function
3. The support for the expiration of emergency mode
4. Audit events tracking the start of emergency mode and the users using the emergency mode.
FND.04 Demonstrate and describe how the technology provides the capability to terminate an electronic session after a predetermined time of inactivity. The capability is demonstrated. AR.FND 01.04 Provide capability to terminate an electronic session after a predetermined time of inactivity. The applicant must describe and demonstrate:
1. The ability to configure the period of inactivity for timeout
2. The ability to prevent further access
3. The ability to prevent further display of information
4. The ability to re-authenticate after inactivity timeout
FND.05 Demonstrate and describe how the technology provides the capability to encrypt and decrypt electronic protected health information. The capability is demonstrated. AR.FND 01.05 Provide the capability to encrypt and decrypt electronic protected health information. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.06 Demonstrate and describe how the technology provides the capability to encrypt data at rest using AES. The capability is demonstrated. AR.FND 01.06 Provide the capability to encrypt data at rest using AES. The applicant must:
1. Identify the media or the location of data at rest
2. Identify the software and/or hardware tools used for encryption
3. Demonstrate the availability (license) of the encryption software
4. Demonstrate access to the tools and available encryption decryption algorithms
5. Demonstrate the availability of the procedure to encrypt and decrypt PHI
6. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.07 Demonstrate and describe how the technology provides the capability to record and examine activity in information systems that contain or use electronic protected health information. The capability is demonstrated. AR.FND 02.01 Provide the capability to record and examine activity in information systems that contain or use electronic protected health information. The applicant must:
1. Describe and demonstrate the capability to detect auditable events
2. Identify the various audit logs being maintained or used (e.g. operating system log, application logs, database logs, infrastructure logs, etc.)
3. display the content of audit records
4. Demonstrate the ability for authorized users to read (readable format) and interpret the information including date and time, user ID/subject ID, event description, system component where the event occurred, and success and failure of the event.
5. Demonstrate the inability of unauthorized users to access the same logs.
6. Describe and demonstrate the ability to maintain consistent time via the use of NPT/SNTP synchronization
7. Describe and demonstrate the protection of audit records (i.e. access only to authorized users/administrators)
FND.08 Demonstrate and describe how the technology provides the capability to use the ATNA profile to communicate audit messages between Secure Nodes and to establish Audit Repository nodes to collect audit information. The capability is demonstrated. AR.FND 02.02 Provide the capability to use the ATNA profile to communicate audit messages between Secure Nodes and to establish Audit Repository nodes to collect audit information. The applicant must describe and demonstrate:
1. The capability to send those audit records which have been collected from different sources (local processes and distributed services) to a central audit log repository.
2. Demonstrate the configuration of the application for ATNA: configuration screens or files.
3. The capability to produce one sample record in the IHE ITI-TF’s XML schema for reporting events that are relevant to security and privacy auditing as specified in the “Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications” (RFC-3881).
FND.09 Person or entity authentication: Demonstrate and describe how the technology provides the capability to verify that a person or entity seeking access to electronic protected health information is the one claimed. The capability is demonstrated. AR.FND 03.01 Person or entity authentication: Provide the capability to verify that a person or entity seeking access to electronic protected health information is the one claimed. The applicant must:
1. Identify all services, connections and protocols used for the purposes such as physician’s remote access, access using a wireless network, connections used for lab test and diagnostic orders, connections to knowledge-bases, exchanging billing information etc.
2. Describe and demonstrate how remote node authentication is done and what open protocol is used for each service.
FND.10 Demonstrate and describe how the technology provides the capability to authenticate users and entities within an organization using Kerberos. The capability is demonstrated. AR.FND 03.02 Provide the capability to authenticate users and entities within an organization using Kerberos. The applicant must:
1. Describe and demonstrate the capability to authenticate users and entities within an organization (e.g. MS Active Directory, 3rd party servers, via application, between web browser and web server, etc.) between client and server or server to server
2. For a Microsoft OS, demonstrate via the security log in the event viewer.
3. For Microsoft Active Directory (which can include non-MS OSs and Web Servers, execute Kerbtray, a Microsoft utility to display ticket information for a given computer running the Kerberos protocol.
4. Execute klist, a utility provided by MIT Kerberos to list credentials (intended for workstations)
5. Show the account creation and active directory being propagated to applications.
FND.11 Demonstrate and describe how the technology implements the EUA Profile (which uses Kerberos) to provide a single sign-on capability within enterprises. The capability is demonstrated. AR.FND 03.03 Implement the EUA Profile (which uses Kerberos) to provide a single sign-on capability within enterprises. 1. Demonstrate SSO capability across enterprise and across multiple applications and platforms.
FND.12 Demonstrate and describe how the technology provides the capability to electronically record individual consumers' consents and authorizations. The capability is demonstrated. AR.FND 04.01 Provide the capability to electronically record individual consumers' consents and authorizations. The applicant must
1. Describe the method used to record consumer’s consents and authorizations.
2. Demonstrate the menus, options and functions via screen displays to prompt and obtain consents and authorizations
3. Demonstrate the menus, and functions to view/retrieve consents and authorizations
FND.13 Demonstrate and describe how the technology provides the capability to create an electronic copy of an individual's electronic health record, to record it on removable media, and to transmit it to a designated entity capable of receiving electronic transmissions. The capability is demonstrated. AR.FND 05.01 Provide the capability to create an electronic copy of an individual's electronic health record, to record it on removable media, and to transmit it to a designated entity capable of receiving electronic transmissions. The capabilities to create an electronic copy of an individual's electronic health record, record it on removable media and transmit it to a designated entity capable of receiving electronic transmissions will be tested with in the clinical scenario under component S and T.
The applicant must:
1. Identify the encryption method and the tools used for standards based encryption of health record on portable media and removable devices
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.14 Demonstrate and describe how the technology provides the capability to create and distribute an electronic copy of an individual's EHR as an unstructured document. The capability is demonstrated. AR.FND 05.02 Provide the capability to create and distribute an electronic copy of an individual's EHR as an unstructured document. The capabilities to create an electronic copy of an individual's electronic health record, record it on removable media, transmit it to a designated entity capable of receiving electronic transmissions and distribute it via PHR, patient portal, CD, USB dive will be tested with in the clinical scenario under component S and T.
The applicant must:
1. Identify the encryption method and the tools used for standards based encryption of health record on portable media and removable devices
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.15 Demonstrate and describe how the technology provides the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The capability is demonstrated. AR.FND 06.01 Provide the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The applicant must:
1. Describe the method used and demonstrate the function to remove the identifiers referenced in section 164.514(b)(2)(i) of HIPAA Privacy Rule.
2. Demonstrate the ability to generate reports of patient information without the identifiers referenced in section 164.514(b)(2)(i) of HIPAA Privacy Rule.
FND.16 Demonstrate and describe how the technology provides the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The capability is demonstrated. AR.FND 06.02 Provide the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The applicant must:
1. Describe the method used to generate and assign a code or other means of record identification
2. Demonstrate the function to generate and assign a code or other means of record identification to allow information to be de-identified via the use of system menus and displays.
FND.17 Demonstrate and describe how the technology provides the capability to protect the code or other means of record identification from unauthorized disclosure. The capability is demonstrated. AR.FND 06.03 Provide the capability to protect the code or other means of record identification from unauthorized disclosure. The applicant must:
1. Identify and demonstrate the method or tools used to prevent access to the code including the use of encryption, hashing, etc.
FND.18 Demonstrate and describe how the technology uses ISO/TS 25237 as guidance in the implementation of pseudonymization capabilities. The capability is demonstrated. AR.FND 06.04 Use ISO/TS 25237 as guidance in the implementation of pseudonymization capabilities. The applicant must:
1. Identify the features, controls, guidelines, protocols rules, etc. implemented from the guide.
2. Demonstrate adherence to the guide.
FND.19 Demonstrate and describe how the technology provides the capability to protect electronic protected health information from improper alteration or destruction. The capability is demonstrated. AR.FND 07.01 Provide the capability to protect electronic protected health information from improper alteration or destruction. The applicant must describe and demonstrate:
1. The capability configured in the product to prevent corruption, improper alteration or loss of data. (e.g., checksums, integrating with a UPS, use of redundant servers/storage, redundant processors, redundant hardware, firewall, IDS, IPS, malware protection, etc.)
2. The threats that have been anticipated, which can lead to loss or corruption of data and the mitigation provided by the system.
3. The use of backup software that can restore to the point of failure, in the event a transaction is corrupted for example due to a sudden power failure.
FND.20 Demonstrate and describe how the technology provides electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. The capability is demonstrated. AR.FND 07.02 Provide electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.21 Demonstrate and describe how the technology provides the capability to use SHA-2 to protect the integrity of data at rest. The capability is demonstrated. AR.FND 07.03 Provide the capability to use SHA to protect the integrity of data at rest. The applicant must:
1. Identify the software tool used for hashing (SHA-2)
2. Demonstrate the menu options and functions
FND.22 If the system uses electronic signature, demonstrate and describe the use of ASTM Standard Guide for Electronic Authentication of Health Care Information: # E1762-95(2003) for the design and implementation of electronic signatures. The capability is demonstrated. AR.FND 07.04 Use as guidance in the design and implementation of electronic signatures. The applicant must:
1. Identify the features, design, controls, guidelines, protocols rules, etc. implemented from the ASTM Standard Guide or required by the product.
2. Demonstrate adherence to the guide.
FND.23 Demonstrate and describe how the technology implements technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. The capability is demonstrated. AR.FND 08.01 Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.24 Integrity controls (Addressable). Demonstrate and describe how the technology implements security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. The capability is demonstrated. AR.FND 08.02 Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.25 Encryption (Addressable). Demonstrate and describe how the technology implements a mechanism to encrypt electronic protected health information whenever deemed appropriate. The capability is demonstrated. AR.FND 08.03 Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.26 Demonstrate and describe how the technology provides the capability to use SHA-2 to protect the integrity of data transmissions. The capability is demonstrated. AR.FND 08.04 Provide the capability to use SHA to protect the integrity of data transmissions. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption (e.g. SHA-2) to ensure that the confidentiality of the PHI being transmitted is protected.
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.27 Demonstrate and describe how the technology provides the capability to use AES to encrypt data for transmission. The capability is demonstrated. AR.FND 08.05 Provide the capability to use AES to encrypt data for transmission. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption AES) to ensure that the confidentiality of the PHI being transmitted is protected.
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.28 Demonstrate and describe how the technology provides the capability to use TLS (with SHA-2 and AES) to establish a mutually authenticated, encrypted, and integrity-protected channel for data exchanges over the World Wide Web. The capability is demonstrated. AR.FND 08.06 Provide the capability to use TLS (with SHA-2 and AES) to establish a mutually authenticated, encrypted, and integrity-protected channel for data exchanges over the World Wide Web. The applicant must:
1. Describe the technical measures taken to use TLS, together with SHA-2 and AES and ensure the use of mutual authentication, encryption and integrity protected channel for data exchanges over the World Wide Web
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.29 If an email capability is provided, demonstrate and describe how the technology implements the CMS standard to cryptographically protect messages, including digital signatures, message digest, message authentication, and content encryption. The capability is demonstrated. AR.FND 08.07 If an email capability is provided, implement the CMS standard to cryptographically protect messages, including digital signatures, message digest, message authentication, and content encryption. If email capability is provided, the applicant must:
1. Demonstrate that the product has implemented the Cryptographic Message Syntax per RFC 2630, -3852 to digitally sign, digest, authenticate, or encrypt arbitrary messages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did ARRA finalize their Product Certification Criteria for Meaningful Use?
I've this version which belongs to October revision.
Here goes the hipaa de-identification requirements as per the information from the above link…
1. FND.15 Demonstrate and describe how the technology provides the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The capability is demonstrated.
2. FND.16 Demonstrate and describe how the technology provides the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The capability is demonstrated
3. FND.17 Demonstrate and describe how the technology provides the capability to protect the code or other means of record identification from unauthorized disclosure. The capability is demonstrated.
Happy New Year, while we're at it.
Question: Does anyone know what the statement that the system must support AES encryption means? Does that apply to disk storage, or to email transactions, or to browser access? What has to be encrypted and how?
Thanks.
- Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noted you posted a screenshot of a form, so I'm assuming you guys coded this. Please submit this code to the 'Code Review' tracker (we prefer a patch from the SF tip, but the SVN tip is ok, or place a package of the complete files) and let Rod and I know via a message on the forum here; then we can give feedback on your code. Better to start as early as possible to avoid some of the pitfalls of OpenEMR coding in future code. This worked out really well with Thomas's group; only took a couple submissions before they got the hang of things.
-brady
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently we are performing the internal code review of HIPAA de-identification code. Will submit the same in the sourcefirge tracker possibly by tomorrow.
Thanks
ViCarePlus Team
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ran ./contrib/util/de-identification_upgrade.php which created the necessary tables.
Then went to openemr/interface/de_identification_forms/de_identification_screen1.php which gave options for producing de-identification data.
Selected ALL, and received the message "De Identification Process is ongoing, Please visit De Identification screen after some time".
No queries or processes are running after checking 30 minutes later.
How do I clear this message and try again?
Thank You
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update the field 'status' to 0 in the table de_identification_status manually. De-identification screen will get displayed normally.
Please ensure you have data in all the required tables.
Thanks,
Vicareplus Team,
services@vicareplus.com
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Team,
HIPAA De-identification is one of the requirements to be considered for CCHIT Certification..
The details of it and the way to implement this in OpenEMR are explained below based on our limited understanding. At this point and based on our analysis, we feel that this needs to be taken care at the OpenEMR side..
Do let us know your views here.
HIPAA De-identification of Patient Health information (PHI) refers to the patients health informations
excluding the information identifying the patient uniquely. (or) It is the process of removing the
identification information from PHI (eg: name, address, contact numbers etc).
The De-identified Patient Health information (PHI) is used for various research, census and other
activities.
According to HIPAA, the de-identified PHI can be obtained by the exclusion of 18 specified
identifiers, which are as follows
1.Names;
2.All geographic subdivisions smaller than a State, including street address, city, county, precinct,
zip code, and their equivalent geocodes, except for the initial three digits of a zip code if,
according to the current publicly available data from the Bureau of the Census:
1.The geographic unit formed by combining all zip codes with the same three initial digits
contains more than 20,000 people; and
2.The initial three digits of a zip code for all such geographic units containing 20,000 or
fewer people is changed to 000.
3.Currently, 036, 059, 063, 102, 203, 556, 592, 790, 821, 823, 830, 831, 878, 879, 884,
890, and 893 are all recorded as "000".
3.All elements of dates (except year) for dates directly related to an individual, including birth
date, admission date, discharge date, date of death; and all ages over 89 and all elements of
dates (including year) indicative of such age, except that such ages and elements may be
aggregated into a single category of age 90 or older;
4.Telephone numbers;
5.Fax numbers;
6.Electronic mail addresses;
7.Social security numbers;
8.Medical record numbers;
9.Health plan beneficiary numbers;
10.Account numbers;
11.Certificate/license numbers;
12.Vehicle identifiers and serial numbers, including license plate numbers;
13.Device identifiers and serial numbers;
14.Web Universal Resource Locator's (URLs);
15.Internet Protocol (IP) address numbers;
16.Biometric identifiers, including finger and voice prints;
17.Full face photographic images and any comparable images; and
18.Any other unique identifying number, characteristic, or code (except as permitted by the reidentification
rules)
The different componets involved here are:
1. Study investigator- who needs the de-identified data for research purposes
2. Central authority (can be HIE/ Public Record Office) – authority who handles the requests for de-identified data from study investigator.
3. Hospitals/Physician practices - which provides De-identitified PHI (database)
The different steps carried out are:
1. Study investigator requests for de-identified PHI data to the central authority.
2. Central authority processes the request and send the request to various medical centers (hospital/physician practices).
3. A medical center on receiving request from central authority, de-identifies the PHI requested and sends the de-identified data to the central authority. (after it is reviewed by the QA team of the same medical center)
4. Central authority receives de-identified data from various medical centers.
5. Central authority holds/stores the origin of the information ( de-identified data) and return the same to the study investigator
Reference
Link:http://worldvista.org/conference_presentations/19th-vista-community-meeting/Deidentified-Slides-3090619.pdf/view
Tasks to be done at the openemr side:
On a broader perspective, the Patient Health Information (PHI) can be divided into,
Structured Data - Defines some finite data (like blood pressure, diagnosis etc)
Unstructured Data - Data in free text format like patient notes, progress notes etc
Based on the deidentification request, the admin (special user) inputs for the required details through a specialized GUI.
(Ex. The data can be retrieved only for a particular diagnosis)
The de-identified data is created using the following algorithm (only the high level logic is given):
1 For each resultant data, a unique reidentification code can be created
2. All the resultant data are processed one by one
a. For all the structured data, if the field is a unique identifier, it is removed directly
b. For the unstructured data, "lexical analysis" is made and if the unique identifier is present in that, it is ignored.
For example, "Joe London has cancer since 5 years" is one of the unstructed data, "Joe London" is removed (and can be replaced by 'xxxx') since this is one of the values for the unique identifier.
The resultant data can be provided as a report and will have the option to convert that as PDF
Do share your views here.
Thanks
ViCarePlus Team
I'm not sure that it's that simple or even possible to remove all identifiers from unstructured data. As per your example, one time the patient might be listed as "Joe London", another time as "Joseph London", another time as "Joe", another time "Joseph", a third time as "Mr London", a fourth time as "Joey Landon" (misspelled). It's relatively easy to remove the first and last name from structured data but I can't see any easy way to recognize all the names in unstructured data.
You may even have a line, "The patient is here with his daughter, Lucretia London-Borgia, who now has his health care proxy."
- Peter
Hi Peter,
The success of de-identification for unstructed data depends on data that is present/loaded into lexical look up table.
Suggestions for what data to be loaded into lexical look up table:
• Known names of patients and hospital staff and other elements specified by HIPAA not be included in de-identified data. (from the openemr database)
• Generic female and male first names, last names, last name prefixes, hospital names, locations and states which can be obtained from other external sources eg:census list etc. (we can provide options to admin to upload these kinds of list to lexical look up table - but not sure whether we can consider this for this phase)
• Design some regular expressions to identify URL's, date, person names etc.
(Eg: name indicators/titles like “Mr. “, “Dr.”, “Ms.” are found, can identify it as name), when a string matches the regular expression it can be ignored.
Do share your views here.
Thanks
ViCarePlus Team
Hi Team,
More details of HIPAA de-identification are present in
Do share your views..
Thanks
ViCarePlus Team
: http://www.openmedsoftware.org/wiki/8._HIPAA_de-identification
This raises the desirability of creating a flexible general-purpose data extraction tool, which might output either a spreadsheet-friendly file, or a "nice" database with a structure that is friendly to report generators. De-identification could then be added to this as an option with relative ease.
Please keep in touch with me about that as I may be asked to do some work in this area soon (without the de-identification).
Rod
(http://www.sunsetsystems.com/)
Hi Rod,
Nice to hear this.. What are the advantages does OpenEMR gain due to this data extraction tool - helpful for custom reports?
We have scheduled to complete this task in another 2-3 weeks and currently we are working on this.
Your inputs are welcome..
Thanks
ViCarePlus Team
Hi.
You have clearly given this a lot of thought, but I still question whether it is possible to effectively de-identify unstructured data. Here are some examples of unstructured data:
" The SEC and FBI have brought an indictment against Raj Rajanatram of Galleon Partners. The key witness is Roomy Khan, who is accused of passing confiidential data about AMD and Intel to Galleon."
"Sponsors have cut back on their ads featuring Tiger Woods."
"Mrs. Colon was found to have Dukes' B colon cancer. Her CEA level is 1.2 and she is scheduled for a CAT scan next week at Presbyterian Hospital in NYC."
To say nothing of the fact that I have a Bangladeshi patient whose first name is "Md", no vowels.
And what happens when someone types in all lower case by accident or laziness? You might be able to pull "Tiger Woods" out of a sentence but it's harder to remove "tiger" or "woods" in lower case, since they are both English words.
Don't you think it would just be better not to export any unstructured data? The adverse consequences of releasing protected health information are so great that it might be better not to risk it.
Thank you for considering my comments.
- Peter
Visolveemr (is this Sena?),
The benefit of a data extraction tool is to gather data in a form that is suitable for import into a spreadsheet, or use by a general-purpose reporting tool like Jasper or Crystal Reports.
However I'm a month or more away from doing that, so don't let me hold you up.
Rod
(http://www.sunsetsystems.com/)
De-Identification (at least for certification purposes) only applies to reports, such as the reports that might be transmitted to immunization registries. It does not apply to free text.
To pass certification we only need to de-identify reports.
Hope this helps
Michael
Hi Michael,
Thanks for your views here..
As part of the policy "Improve population and public health", here goes the two meaningful objectives defined..
a. Submit electronic data to immunization registries where required and accepted.
b. Provide electronic syndrome sureveillance data to public health agencies according to applicable law and practice
Immunization data is the structured data. What kind of data we need to pass for (b).. ?
Peter, thanks for your views.. lets hear the expectation of CCHIT from Michael..
Thanks
ViCarePlus team
Hi Rod,
Yes…. this is the ViCarePlus team (of Visolve) headed by Sena Palanisami.
Thanks for your views..
thanks
ViCarePlus team
oth of these are considered optional by CCHIT. They believe they will NOT be part of the final definition of meaninful use.
That being said, if the software has the ability to send a CCD that contains the appropriate information, the software will pass these modules.
Michael
Hi Michael,
Thanks for sharing your views on HIPAA de-identification.
You'd mentioned previously that we need not concentrate on unstructured data for HIPAA De-identification. Can you provide some links to that (if you've any) so that we can preserve the same for our future reference.
In your later mail, the meaningful objectives what you've mentioned as optional applies to HIPAA de-identification??
Thanks for your help here.
Thanks
ViCarePlus Team
I have a document from CCHIT, unfortunately this site does not accept uploads. I will try a 'paste' of it in a moment.
Michael
Foundational Infrastructure Test Scripts Guidance
For ARRA Preliminary 2011 EHR Technology
November 5, 2009
Product (NUMBER CODE ONLY):_________________________ Date: __________________________
Evaluator: _________________________________________ Signature: _______________________
FOUNDATIONAL INFRASTRUCTURE: Security and Privacy (MU.P5.G1)
All test steps must be demonstrated. The applicant explicitly attests to the veracity of the features and functions demonstrated, the information furnished, and the statements made during the course of this inspection.
Exception: Test steps that are optional are highlighted in yellow. These steps are to be demonstrated if possible, but will not affect certification results.
Procedure Expected Result Criteria and Reference Vendor/Juror Guidance
FND.01 Demonstrate and describe how the technology provides the capability to allow access only to those persons or software programs that have been granted access rights. The capability is demonstrated. AR.FND 01.01 Provide capability to allow access only to those persons or software programs that have been granted access rights. The applicant must describe and demonstrate:
1. The ability to provide access only to authenticated users
2. The authentication procedure (e.g. account creation including user IDs, assignment of privileges,
3. The access control method, user-based, RBAC, SSO, EUA, SAML, context-based, etc.
4. The product’s password strength rule and password security (age, reuse, display, encryption, etc.)
5. The product’s limit of number of consecutive invalid attempt
6. The product’s Account lockout after exceeding the limit of number of invalid attempt:
- configurable time delay until next login
attempt
- require release by administrator
7. The ability to suspend user accounts
8. The history of inactive accounts
9. The ability to configure and display notice of warning against unauthorized use
10. The ability to generate audit record for valid logins and invalid login attempts
FND.02 Demonstrate and describe how the technology provides the capability to assign a unique name and/or number for identifying and tracking user identity. The capability is demonstrated. AR.FND 01.02 Provide capability to assign a unique name and/or number for identifying and tracking user identity. The applicant must describe and demonstrate:
1. Uniqueness of user IDs
2. Composition of user IDs
3. Case sensitivity and case insensitivity of user IDs
4. The ability to track user IDs in audit records
5. The ability to generate audit records for valid logins and invalid login attempts with user IDs
FND.03 Demonstrate and describe how the technology provides the capability to access necessary electronic protected health information during an emergency. The capability is demonstrated. AR.FND 01.03 Provide capability to access necessary electronic protected health information during an emergency. The applicant must describe and demonstrate:
1. The support for emergency access policies
2. The method supported for clinical user access in emergency situations also known as the break-the-glass function
3. The support for the expiration of emergency mode
4. Audit events tracking the start of emergency mode and the users using the emergency mode.
FND.04 Demonstrate and describe how the technology provides the capability to terminate an electronic session after a predetermined time of inactivity. The capability is demonstrated. AR.FND 01.04 Provide capability to terminate an electronic session after a predetermined time of inactivity. The applicant must describe and demonstrate:
1. The ability to configure the period of inactivity for timeout
2. The ability to prevent further access
3. The ability to prevent further display of information
4. The ability to re-authenticate after inactivity timeout
FND.05 Demonstrate and describe how the technology provides the capability to encrypt and decrypt electronic protected health information. The capability is demonstrated. AR.FND 01.05 Provide the capability to encrypt and decrypt electronic protected health information. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.06 Demonstrate and describe how the technology provides the capability to encrypt data at rest using AES. The capability is demonstrated. AR.FND 01.06 Provide the capability to encrypt data at rest using AES. The applicant must:
1. Identify the media or the location of data at rest
2. Identify the software and/or hardware tools used for encryption
3. Demonstrate the availability (license) of the encryption software
4. Demonstrate access to the tools and available encryption decryption algorithms
5. Demonstrate the availability of the procedure to encrypt and decrypt PHI
6. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.07 Demonstrate and describe how the technology provides the capability to record and examine activity in information systems that contain or use electronic protected health information. The capability is demonstrated. AR.FND 02.01 Provide the capability to record and examine activity in information systems that contain or use electronic protected health information. The applicant must:
1. Describe and demonstrate the capability to detect auditable events
2. Identify the various audit logs being maintained or used (e.g. operating system log, application logs, database logs, infrastructure logs, etc.)
3. display the content of audit records
4. Demonstrate the ability for authorized users to read (readable format) and interpret the information including date and time, user ID/subject ID, event description, system component where the event occurred, and success and failure of the event.
5. Demonstrate the inability of unauthorized users to access the same logs.
6. Describe and demonstrate the ability to maintain consistent time via the use of NPT/SNTP synchronization
7. Describe and demonstrate the protection of audit records (i.e. access only to authorized users/administrators)
FND.08 Demonstrate and describe how the technology provides the capability to use the ATNA profile to communicate audit messages between Secure Nodes and to establish Audit Repository nodes to collect audit information. The capability is demonstrated. AR.FND 02.02 Provide the capability to use the ATNA profile to communicate audit messages between Secure Nodes and to establish Audit Repository nodes to collect audit information. The applicant must describe and demonstrate:
1. The capability to send those audit records which have been collected from different sources (local processes and distributed services) to a central audit log repository.
2. Demonstrate the configuration of the application for ATNA: configuration screens or files.
3. The capability to produce one sample record in the IHE ITI-TF’s XML schema for reporting events that are relevant to security and privacy auditing as specified in the “Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications” (RFC-3881).
FND.09 Person or entity authentication: Demonstrate and describe how the technology provides the capability to verify that a person or entity seeking access to electronic protected health information is the one claimed. The capability is demonstrated. AR.FND 03.01 Person or entity authentication: Provide the capability to verify that a person or entity seeking access to electronic protected health information is the one claimed. The applicant must:
1. Identify all services, connections and protocols used for the purposes such as physician’s remote access, access using a wireless network, connections used for lab test and diagnostic orders, connections to knowledge-bases, exchanging billing information etc.
2. Describe and demonstrate how remote node authentication is done and what open protocol is used for each service.
FND.10 Demonstrate and describe how the technology provides the capability to authenticate users and entities within an organization using Kerberos. The capability is demonstrated. AR.FND 03.02 Provide the capability to authenticate users and entities within an organization using Kerberos. The applicant must:
1. Describe and demonstrate the capability to authenticate users and entities within an organization (e.g. MS Active Directory, 3rd party servers, via application, between web browser and web server, etc.) between client and server or server to server
2. For a Microsoft OS, demonstrate via the security log in the event viewer.
3. For Microsoft Active Directory (which can include non-MS OSs and Web Servers, execute Kerbtray, a Microsoft utility to display ticket information for a given computer running the Kerberos protocol.
4. Execute klist, a utility provided by MIT Kerberos to list credentials (intended for workstations)
5. Show the account creation and active directory being propagated to applications.
FND.11 Demonstrate and describe how the technology implements the EUA Profile (which uses Kerberos) to provide a single sign-on capability within enterprises. The capability is demonstrated. AR.FND 03.03 Implement the EUA Profile (which uses Kerberos) to provide a single sign-on capability within enterprises. 1. Demonstrate SSO capability across enterprise and across multiple applications and platforms.
FND.12 Demonstrate and describe how the technology provides the capability to electronically record individual consumers' consents and authorizations. The capability is demonstrated. AR.FND 04.01 Provide the capability to electronically record individual consumers' consents and authorizations. The applicant must
1. Describe the method used to record consumer’s consents and authorizations.
2. Demonstrate the menus, options and functions via screen displays to prompt and obtain consents and authorizations
3. Demonstrate the menus, and functions to view/retrieve consents and authorizations
FND.13 Demonstrate and describe how the technology provides the capability to create an electronic copy of an individual's electronic health record, to record it on removable media, and to transmit it to a designated entity capable of receiving electronic transmissions. The capability is demonstrated. AR.FND 05.01 Provide the capability to create an electronic copy of an individual's electronic health record, to record it on removable media, and to transmit it to a designated entity capable of receiving electronic transmissions. The capabilities to create an electronic copy of an individual's electronic health record, record it on removable media and transmit it to a designated entity capable of receiving electronic transmissions will be tested with in the clinical scenario under component S and T.
The applicant must:
1. Identify the encryption method and the tools used for standards based encryption of health record on portable media and removable devices
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.14 Demonstrate and describe how the technology provides the capability to create and distribute an electronic copy of an individual's EHR as an unstructured document. The capability is demonstrated. AR.FND 05.02 Provide the capability to create and distribute an electronic copy of an individual's EHR as an unstructured document. The capabilities to create an electronic copy of an individual's electronic health record, record it on removable media, transmit it to a designated entity capable of receiving electronic transmissions and distribute it via PHR, patient portal, CD, USB dive will be tested with in the clinical scenario under component S and T.
The applicant must:
1. Identify the encryption method and the tools used for standards based encryption of health record on portable media and removable devices
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.15 Demonstrate and describe how the technology provides the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The capability is demonstrated. AR.FND 06.01 Provide the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The applicant must:
1. Describe the method used and demonstrate the function to remove the identifiers referenced in section 164.514(b)(2)(i) of HIPAA Privacy Rule.
2. Demonstrate the ability to generate reports of patient information without the identifiers referenced in section 164.514(b)(2)(i) of HIPAA Privacy Rule.
FND.16 Demonstrate and describe how the technology provides the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The capability is demonstrated. AR.FND 06.02 Provide the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The applicant must:
1. Describe the method used to generate and assign a code or other means of record identification
2. Demonstrate the function to generate and assign a code or other means of record identification to allow information to be de-identified via the use of system menus and displays.
FND.17 Demonstrate and describe how the technology provides the capability to protect the code or other means of record identification from unauthorized disclosure. The capability is demonstrated. AR.FND 06.03 Provide the capability to protect the code or other means of record identification from unauthorized disclosure. The applicant must:
1. Identify and demonstrate the method or tools used to prevent access to the code including the use of encryption, hashing, etc.
FND.18 Demonstrate and describe how the technology uses ISO/TS 25237 as guidance in the implementation of pseudonymization capabilities. The capability is demonstrated. AR.FND 06.04 Use ISO/TS 25237 as guidance in the implementation of pseudonymization capabilities. The applicant must:
1. Identify the features, controls, guidelines, protocols rules, etc. implemented from the guide.
2. Demonstrate adherence to the guide.
FND.19 Demonstrate and describe how the technology provides the capability to protect electronic protected health information from improper alteration or destruction. The capability is demonstrated. AR.FND 07.01 Provide the capability to protect electronic protected health information from improper alteration or destruction. The applicant must describe and demonstrate:
1. The capability configured in the product to prevent corruption, improper alteration or loss of data. (e.g., checksums, integrating with a UPS, use of redundant servers/storage, redundant processors, redundant hardware, firewall, IDS, IPS, malware protection, etc.)
2. The threats that have been anticipated, which can lead to loss or corruption of data and the mitigation provided by the system.
3. The use of backup software that can restore to the point of failure, in the event a transaction is corrupted for example due to a sudden power failure.
FND.20 Demonstrate and describe how the technology provides electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. The capability is demonstrated. AR.FND 07.02 Provide electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.21 Demonstrate and describe how the technology provides the capability to use SHA-2 to protect the integrity of data at rest. The capability is demonstrated. AR.FND 07.03 Provide the capability to use SHA to protect the integrity of data at rest. The applicant must:
1. Identify the software tool used for hashing (SHA-2)
2. Demonstrate the menu options and functions
FND.22 If the system uses electronic signature, demonstrate and describe the use of ASTM Standard Guide for Electronic Authentication of Health Care Information: # E1762-95(2003) for the design and implementation of electronic signatures. The capability is demonstrated. AR.FND 07.04 Use as guidance in the design and implementation of electronic signatures. The applicant must:
1. Identify the features, design, controls, guidelines, protocols rules, etc. implemented from the ASTM Standard Guide or required by the product.
2. Demonstrate adherence to the guide.
FND.23 Demonstrate and describe how the technology implements technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. The capability is demonstrated. AR.FND 08.01 Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.24 Integrity controls (Addressable). Demonstrate and describe how the technology implements security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. The capability is demonstrated. AR.FND 08.02 Integrity controls (Addressable). Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of. The applicant must :
1. Describe and demonstrate the capability to use checksums
2. Describe and demonstrate the capability to use hashing
3. Describe and demonstrate the capability to detect and create audit trail
4. Describe the technical security measures employed to guard against unauthorized access to the PHI being transmitted
5. Identify the secure transmission method used (e.g., VPN, open protocols such as SSL and TLS)
6. Identify the hashing method and the tools used for standards based hashing (e.g. SHA2) to ensure that the transaction has not been tampered in transit
7. Identify the encryption method and the tools used for standards based encryption (e.g. AES) to ensure that the confidentiality of the PHI being transmitted is protected.
8. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require SHA2 (SHA1 excluded) and AES (3DES and other algorithms are excluded).
FND.25 Encryption (Addressable). Demonstrate and describe how the technology implements a mechanism to encrypt electronic protected health information whenever deemed appropriate. The capability is demonstrated. AR.FND 08.03 Encryption (Addressable). Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption
2. Demonstrate the availability (license) of the encryption software
3. Demonstrate access to the tools and available encryption/decryption algorithms
4. Demonstrate the availability of the procedure to encrypt and decrypt PHI
5. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
Note: HHS’ proposed standards require AES (3DES and other algorithms are excluded).
FND.26 Demonstrate and describe how the technology provides the capability to use SHA-2 to protect the integrity of data transmissions. The capability is demonstrated. AR.FND 08.04 Provide the capability to use SHA to protect the integrity of data transmissions. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption (e.g. SHA-2) to ensure that the confidentiality of the PHI being transmitted is protected.
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.27 Demonstrate and describe how the technology provides the capability to use AES to encrypt data for transmission. The capability is demonstrated. AR.FND 08.05 Provide the capability to use AES to encrypt data for transmission. The applicant must:
1. Identify the encryption method and the tools used for standards based encryption AES) to ensure that the confidentiality of the PHI being transmitted is protected.
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.28 Demonstrate and describe how the technology provides the capability to use TLS (with SHA-2 and AES) to establish a mutually authenticated, encrypted, and integrity-protected channel for data exchanges over the World Wide Web. The capability is demonstrated. AR.FND 08.06 Provide the capability to use TLS (with SHA-2 and AES) to establish a mutually authenticated, encrypted, and integrity-protected channel for data exchanges over the World Wide Web. The applicant must:
1. Describe the technical measures taken to use TLS, together with SHA-2 and AES and ensure the use of mutual authentication, encryption and integrity protected channel for data exchanges over the World Wide Web
2. Demonstrate the menus, functions, options and the choice for selecting or implementing the methods identified above
FND.29 If an email capability is provided, demonstrate and describe how the technology implements the CMS standard to cryptographically protect messages, including digital signatures, message digest, message authentication, and content encryption. The capability is demonstrated. AR.FND 08.07 If an email capability is provided, implement the CMS standard to cryptographically protect messages, including digital signatures, message digest, message authentication, and content encryption. If email capability is provided, the applicant must:
1. Demonstrate that the product has implemented the Cryptographic Message Syntax per RFC 2630, -3852 to digitally sign, digest, authenticate, or encrypt arbitrary messages.
It really did not paste well. If you want the original word document let me know.
Michael
Hi Michael,
Thanks for your help here.
Can you please send the original document to vicareplus_engg@visolve.com?
Thanks
ViCarePlus Team
Hi Michael,
Did ARRA finalize their Product Certification Criteria for Meaningful Use?
I've this version which belongs to October revision.
Here goes the hipaa de-identification requirements as per the information from the above link…
1. FND.15 Demonstrate and describe how the technology provides the capability to remove the identifiers enumerated in Section 164.514(b)(2)(i) of the HIPAA Privacy Rule. The capability is demonstrated.
2. FND.16 Demonstrate and describe how the technology provides the capability to generate and assign a code or other means of record identification to allow information de-identified in accordance with the HIPAA Privacy Rule to be re-identified by the covered entity; such code or other means must not be derived from or related to the information and must not be otherwise capable of being translated so as to disclose the identity of the individual. The capability is demonstrated
3. FND.17 Demonstrate and describe how the technology provides the capability to protect the code or other means of record identification from unauthorized disclosure. The capability is demonstrated.
Thanks
ViCarePlus Team
: http://health.state.mn.us/e-health/standards/certrecs102609.pdf
: http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_880497_0_0_18/PRIVACY%20AND%20SECURITY%20STANDARDS%20APPLICABLE%20TO%20ARRA%20REQUIREMENTS.pdf
Hi Team,
HIPAA de-identification/re-identification input options and output format are described in
Thanks
ViCarePlus Team
: http://www.openmedsoftware.org/wiki/8._HIPAA_de-identification
As of now 9:20 am Eastern Time it has not been published. Law states it must be published by the end of the day on Dec 31.
But then again when does the government care about the law??
Michael
Happy New Year, while we're at it.
Question: Does anyone know what the statement that the system must support AES encryption means? Does that apply to disk storage, or to email transactions, or to browser access? What has to be encrypted and how?
Thanks.
- Peter
VicarePlus Team,
I noted you posted a screenshot of a form, so I'm assuming you guys coded this. Please submit this code to the 'Code Review' tracker (we prefer a patch from the SF tip, but the SVN tip is ok, or place a package of the complete files) and let Rod and I know via a message on the forum here; then we can give feedback on your code. Better to start as early as possible to avoid some of the pitfalls of OpenEMR coding in future code. This worked out really well with Thomas's group; only took a couple submissions before they got the hang of things.
-brady
Hi Brady,
Currently we are performing the internal code review of HIPAA de-identification code. Will submit the same in the sourcefirge tracker possibly by tomorrow.
Thanks
ViCarePlus Team
Hi,
Ran ./contrib/util/de-identification_upgrade.php which created the necessary tables.
Then went to openemr/interface/de_identification_forms/de_identification_screen1.php which gave options for producing de-identification data.
Selected ALL, and received the message "De Identification Process is ongoing, Please visit De Identification screen after some time".
No queries or processes are running after checking 30 minutes later.
How do I clear this message and try again?
Thank You
Hi,
Update the field 'status' to 0 in the table de_identification_status manually. De-identification screen will get displayed normally.
Please ensure you have data in all the required tables.
Thanks,
Vicareplus Team,
services@vicareplus.com