Specifically to my attention is the question of Security and Privacy relative to the new MU2 method of Modular Certification. This 'problem' has been identified very well by Dixie Baker on the HIT blog
The biggest problem here is that there is no definition of what a Module is. Thus there are some Modules that are nothing but reporting packages that make output look pretty for printing, these kinds of Modules should not have the security imposed upon them but rather the ‘calling’ application should have already done all necessary security and privacy tasks. However many Modules are closer to a full functional specialty or departmental systems.
Note that MU2 already has an equivalent of this. The defined "Transports" are a exemplar of what I am talking about. The Transports include security built right in. This security is well defined and clear.
This is easy to do with some Modules, not so easy with others. But by starting with some easy Modules, such as departmental EHRs, we can narrow the gap. There are well defined standards interfaces, interoperability, between the main EHR and the departmental EHR.
- Patient Identity -- IHE-PIX, IHE-PDQ, and IHE-PAM
- Orders/Results -- IHE Radiology Scheduled Workflow, IHE-Laboratory Workflow, etc
- Care coordination documentation -- HL7 v2 MDM, CDA, CCDA, IHE
Once these interfaces are defined, one looks at the interface requirements. Sometimes the security need only be machine-to-machine (IHE-ATNA). But sometimes user identity is important (IHE-EUA, IHE-XUA, or IHE-IUA). A big advantage of having these modules well defined and interfaces well defined are that one can also look at deeper requirements like Encryption, Security Audit, Privacy Enforcement, Accounting of Disclosures, Amendments, and accessibility.
The problem that MU has with this is that I don’t think HHS/ONC/CMS want to get into the internal workings of a healthcare provider operation. Inside the healthcare provider operational IT is a mess. Most of the healthcare provider organizations that have complex internal operational IT, also have plenty of knowledge and power to change it themselves. Thus I don’t think there is really a desire in HHS to mess with the problem of internal organizational affairs. I also don’t think that the large organizations want HHS messing around in their internal affairs.
I think a logical move for MU3 is to head a little bit back toward MU1 method of modularity without going all the way back. Thus I think there is a need to have some defined types of specialty EHR that are required to meet all security/privacy requirements, and have defined interfaces. These defined types should be rather identifiable and their interactions also rather clear.
- MU Patient Engagement - Activity History Log
- MU2 - Why must healthcare use custom software when Thunderbird and Outlook would do?
- 2014 Draft Test Methods: Wave Four Released for Public Review and Comment
- MU2 - Encryption and Hashing
- Patient Portal - view, download, TRANSMIT
- Meaningful Use Stage 2 - Transports Clarified --
- MU2 Wave 1 of Draft Test Procedures -- Integrity Problem
- On The Meaningful Use Stage 2 Rules
- Meaningful Use Stage 2 : Transports
- Meaningful Use Stage 2 - Audit Logging - Privacy and Security
- Minimal Metadata
- Karen's Cross or just Minimal Metadata