It’s hard to determine system security requirements in the absence of solution architecture

In the health IT arena, a lot of energy is currently focused on measures, criteria, and standards with which health care providers and other entities can demonstrate “meaningful use” of electronic health record (EHR) systems and thereby qualify for reimbursement and other financial incentives for adopting EHR technology, under a Recovery Act-funded program administered by CMS. In an interim final rule released on December 30 that took effect on February 12, the Office of the National Coordinator, working through the Health IT Standards Committee (an advisory body also created by a provision of the Recovery Act), published a set of functional criteria and associated standards to be used to certify that EHR modules and systems can support meaningful use. As expected, much of the commentary submitted to the Standards Committee related to the security-specific criteria and standards in the IFR focus on establishing the appropriate level of specificity for functional criteria, and on when it makes sense to require the use of specific technical standards. In many ways the consideration of EHR systems in isolation mirrors the information system-centric approach to security favored by the federal government, and to the extent that the criteria in the rule will be used as a product certification checklist, this may be appropriate. However, when considering functional and technical requirements related to the way organizations using EHR technology will exchange information, it is essential to include the environmental context in which the systems operate, in order to assign requirements to the appropriate components in the overall solution.

As a case in point, at a meeting on February 24 the Privacy and Security Workgroup of the Health IT Standards Committee identified in its comments and recommendations on the IFR what the workgroup calls a “critical gap” in the criteria and standards because they do not address the need to authenticate end points of the secure communication channels that an organization using an EHR system must  use to exchange information with other entities. At first glance it might make sense to require the EHR system to offer this capability, but when considering a typical point-to-point integration architecture between two entities, it’s not that likely that the EHR system itself will serve as one of the end points in the transmission. What’s far more typical is that any information to be exchanged will be transmitted using an integration gateway, adapter, application server, or even web server depending on the type of information exchange being implemented. For instance, the service specifications for the Nationwide Health Information Network (NHIN), which include the required use of a mutually authenticated secure communication channel, presume the use of intermediary communication components such as the government-produced Connect open-source gateway software, to which internal entity systems would be integrated and which handle functions like establishing TLS sessions with information exchange partners, generating identification and authentication assertions, and applying digital signatures using entity-specific X.509 certificates issued to NHIN participating entities. An internal medical record keeping system in the sort of NHIN-connected scenario envisioned by ONC wouldn’t directly connect with any external systems at all, so there wouldn’t be a need for the EHR system to be able to establish a secure communication channel on its own. Of course, there are many potential ways to implement health information exchange that don’t involve the NHIN, but the point is any required certification criteria that will be used in part to determine eligibility for EHR incentives should match functional capabilities that EHR systems will need in typical implementation scenarios, not in the abstract.