Like or Dislike: 0  0 (0)

Like or Dislike: 0  0 (0)

Like or Dislike: 0  0 (0)

Like or Dislike: 0  0 (0)

Like or Dislike: 1  0 (+1)

Like or Dislike: 0  0 (0)

For example: we have found transmission encryption and backup storage; however, we’ve seen nothing of backup encryption as in off-site storage (backup tapes carried to an alternate location in case of disaster). Although the alternate location may be secure, the backup media must travel between the two and should be encrypted. All documentation only states backups should be as secure as the data it has backed up. This does not address backup media in-route as being insecure!

Example 2: Format or form of access provided includes USB drives; however, there is no mention of required encryption levels. Without specified encryption, a USB storage device that falls from a briefcase or pocket during a quick stop for coffee PHI/PII is now vulnerable to PHI/PII access. Drive encryption was only required for telework; however, many agencies do not have true teleworkers, so the section is disregarded.

Example 3: Physical security has been marginally addressed; however, what security should a server/server room have? Should server be place away from exterior walls? Should it have controlled access?

There are many documents that provide a synopsis, summary, or generalized description of each requirement; however, there a many questions that are currently unclear or unanswered.

Neither the NIST documentation nor the Health Information Technology page provides any definitive answers or security assessment/checklist.

Is there a complete consolidated Security Checklist for Information Technology/Information Systems? If not, is it being developed?

Like or Dislike: 2  0 (+2)

The Policy Committee’s attempt to frame governance principles for the Nationwide Health Information Network is premature, because no one – in the Office of the National Coordinator, the Policy or the Standards Committees, the health information technology industry, nor anywhere else – yet knows the design for the NHIN (or whatever its new name will be). Consequently, no one yet knows what is to be governed, or how it will operate; and governance is fundamentally unsolvable in the abstract.

Knowing the system design and technological underpinnings for engineering a socio-technical system is a prerequisite – essential – to governing it. In this case, making progress on many NHIN requirements under the HITECH Act, including establishing “a governance mechanism” (Section 3001(c)(8)), first requires knowing the NHIN’s design, at least at a high level. ONC current document describing the NHIN’s architecture does not furnish enough structure or technical detail about information exchange for this purpose.

The HITECH Act requires the Secretary of HHS to determine how “electronic health information” will be exchanged securely and integrated with health information from a variety of “Qualified Electronic Health Record” sources (Section 3000(13)(B)(iv)). In common parlance, ONC, acting for the Secretary, must at some level solve the problem of interoperability for disparate legacy systems. That in turn demands standards-setting in some fashion at the federal level.

Standards have not yet been set for “the system after next.” Standards only have been offered on a stopgap basis for NHIN Direct (now just “Direct”). Direct is a plan for secure electronic mail, based on relatively simple content and messaging standards, to replace facsimile, which is the U.S.’s present system for exchanging health records. So, though industry and government have some notion of what Direct will look like, we know little about what technology the NHIN will use, how it will operate, and – hence – how it might or should be governed.

The folly of trying to frame governance for an unknown system comes through clearly in the Governance Workgroup’s October 18, 2010 “Preliminary Recommendations.” The nine “Sound Governance Principles” are abstract to the point of having almost no utility in guiding the development of concrete governance structures and processes, given that ONC has yet to prescribe in useful engineering detail “the system after next’s” architecture, technologies, and business processes within the framework specified by the HITECH Act.

Worse, the Governance Workgroup’s recommendations are dazzlingly complicated. Who knows how they would or could be applied to an NHIN once engineered? This attempt to apply abstraction to the unknown would result in far more governance, and therefore operational, complexity than necessary. Defining governance in advance of defining the thing being governed would almost inevitably create governance structures that turn out to be irrelevant or counterproductive, while neglecting things that must, in the end, be governed – thereby leaving the door open to additional structure that creates unnecessary operational complexity. That in turn would produce significant unnecessary expense to run the NHIN once it finally starts to operate. If nothing else, our current national debate makes clear that building foreseeable unnecessary expense – waste – into NHIN governance, and therefore into the NHIN itself, is unacceptable.

There is another important reason for ONC to suspend work on NHIN governance. If ONC decides to adopt an Ultra Large Scale Systems perspective to design the NHIN “system after next” (possibly to be called NHIN “Exchange”), one of the likely benefits is that governance as required by HITECH Section 3001(c)(8) can be greatly simplified. In a ULS Systems implementation of the NHIN, a fundamental initial requirement is likely to be for institutional clinical systems and consumer-controlled systems to write to and read from a common communications bus (much like Direct). The computer processing that goes on inside institutional perimeters will then be the responsibility of the institution (a hospital, doctors’ office, or research institution, for example). A ULS System approach would thereby simplify governance, promote local innovation, and lower local and nationwide costs.

Because a ULS System architecture, at scale, has no need for consensus among legacy health IT system operators (hospitals, physician offices, health insurers, pharmacies, government agencies, research institutions, and so forth) on how they should operate within local boundaries, the ULS System methodology does not require comprehensive internal design and operating standards for each legacy system, for new clinical, research, or public health oversight systems, or for consumer-owned systems such as health record banks that connect to the NHIN. A ULS Systems-based NHIN would, at scale, therefore accommodate highly diverse systems with minimal national-level governance. The local systems, or nodes, could connect to the NHIN communications network using open data translation protocols to standardize management of information exchange. This would obviate the need to standardize internal workings of separate clinical systems or the collection of clinical and other data systems that operate, for example, within the periphery of a large medical center or any other node of whatever size. The ULSS architecture preserves capacities for local operating autonomy and innovation throughout nodes on the NHIN. Nodes can join the NHIN so long as they accommodate its open data translation protocols, including security and privacy requirements. Consequently, the architecture itself simplifies operating and governance requirements, and – very important – lowers costs.

(For an explanation of Ultra Large Scale Systems methodology and how its perspective applies to conquering interoperability challenges of the NHIN, see Kevin Sullivan, et al., “An Ultra-Large-Scale Systems Approach to National-Scale Health Information Systems,” presented at FoSER 2010, Nov. 7-8, 2010, Santa Fe, N.M. (proceedings at http://portal.acm.org/citation.cfm?id=1882362&picked=prox&CFID=802122&CFTOKEN=14823262; article available at http://www.cs.virginia.edu/~sullivan/uls-hit.pdf.)

This ULSS-derived architecture also allows the NHIN to evolve ever-greater capabilities as the open data protocols become more capable, that is, smarter. Governance for this process will of course be necessary. However, that kind of standards development is well within traditional federal government functions, and does not necessitate the numbing interplay of governmental and private governance structures, functions, and principles that seem to be contemplated by the Governance Workgroup’s October 18 Preliminary Recommendations.

These views are consistent with the criticisms of other commenters. We want particularly to support the December 5 comments submitted by Fred Trotter, highlighting the need for policy recommendations from ONC advisory committees to have much better grounding in technological reality. The Policy Committee continues to offer recommendations that available technology will not support. Consequently, the policy framework that seems to be evolving for the NHIN is itself unnecessarily complicated, too expensive, and a distraction from technical and policy questions bearing on the core “system after next” interoperability challenges that remain for ONC to address.

Our views also are consistent with those in the report, Realizing the Full Potential of Health Information Technology to Improve Healthcare for Americans: The Path Forward, released today by the President’s Council of Advisors on Science and Technology (PCAST). PCAST’s strong recommendation is that ONC focus on developing the capability for universal health data exchange. PCAST recommends this be done by creating and disseminating a universal exchange language for healthcare information and an infrastructure for locating patient records, while rigorously protecting privacy and security. The Ultra Large Scale Systems approach offers highly suitable organizing principles to meet this engineering and architectural challenge.

For these reasons, we believe the Ultra Large Scale Systems perspective offers the most realistic prospect for ONC to undertake a productive NHIN systems analysis, develop a systems design, and begin to engineer the “system after next” for secure, affordable, routine, practical interchange of health information in digital form. Among other things, a ULSS-derived architecture is essential to involving consumers in managing their health and health care, improving data management for clinicians and researchers, and thus lowering national healthcare costs.

Attempting to proceed with NHIN governance abstractions at the present time really does not serve the statutory purpose, because we are not at the point where ONC, even with its many advisors, knows enough about the NHIN’s eventual architecture to produce a useful and affordable “governance mechanism.” Governance issues can and should wait until the ULS Systems design process yields a high-level picture of the NHIN system. Indeed, governance considerations should be part of the ULSS-derived systems analysis that will initiate the system design process. When high-level and detailed governance discussions are postponed to that point and conducted in that context, ONC and its advisory committees and industry will be far better positioned to know what actually is to be governed, how it will operate, and therefore what system governance properly should ignore, as well as what it should address.

Like or Dislike: 2  0 (+2)

I worked on the Security and Trust Working Group for the Direct Project, which forms one of the two approved protocols on the NHIN. I am somewhat informed regarding the other project CONNECT and the IHE protocols it implements.

In the Direct Project Security and Trust working group, we took -great- care to ensure that our work, would not trample the ability of HITPC or ONC to make reasonable (or for that matter unreasonable) decisions about how trust, security and privacy should be made. However, out of necessity, we did have to choose a technology stack and specific protocol configurations in order to get any kind of working system in place. Those decisions were not intended to limit your ability to make policy decisions, except in one important way; to quote the current version of the introduction to our Direct Project Security Overview: “In some cases, these protocols and technologies will come with specific configuration options that will have policy implications and may also present constraints that Direct Project will force on the trust policies of its users.”

In short, we asked that you implement your policy decisions in terms of the technology choices that we made. Most specifically we chose X.509 as a protocol for managing trust relationships. This is the same underlying trust architecture that is implemented in IHE and CONNECT. Rather than honor this basic request, to speak in relevant technological terms, HITPC has largely decided to recommend ‘in the abstract’. HITPC has ignored the fact that the fundamental designs of both Direct and IHE dictate that certain security and policy issues -must- be answered, and renders other issues irrelevant.

For instance, your document asks: ‘When is exchange not considered NW-HIN and, therefore, not subject to NW-HIN governance? ‘ While this may be a relevant question for those under the IHE protocol, the Direct protocol ‘Circle of Trust’ concept supersedes this questions basic premise. Its not the ‘answers’ the question… it just makes it irrelevant. With Circles of Trust participating in the ‘official NW-HIN’ is a fluid concept. Nodes will float freely in and out of any given definition of what ‘official NW-HIN’ means.

However, in your “what to do plans” you note that you expect to: “Establish technical requirements to assure policy and technical interoperability.” With all due respect, that work is largely done, and what little remains will be finished by participants in the Direct and CONNECT projects. Moreover, any ‘governance’ of these issues, that cannot influence the contents of reference implementations of the IHE and Direct protocols is mostly just blowing smoke. ‘policy and technical interoperability’ will be 100% dictated by what the Direct and CONNECT programmers put into those projects. Which means that for any governance body to get ‘policy and technical interoperability’, that body will need to be deeply linked in with the developers of those projects. So far there has been a substantial breakdown between what we the developers have asked for as far as policy guidance and what we have been given. Most of the advice from the Security and Privacy Tiger Team, while well-intentioned, made extremely poor technical assumptions and did not begin to approach the actual issues that we needed to address. For the most part, HITPC discussions of Security and Privacy have been a distraction to those of us actually deciding how things where going to be implemented.

Which brings me to what I think is the really only relevant issue here: Who should be on the governance board for the NW-HIN.

The answer to that question is pretty straight forward to me: You need to have at least one representatives from the Security and Trust developers from each of the two projects. Preferably the people who are actually involved with the implementation of the relevant portions of the code. (which rules me out sadly).

Moreover, -every- other member of the governance body should be well-versed in X-509. This means that it should be made up -entirely- of people who are both technology and policy fluent. If the members of a governance board are uncomfortable discussing revocation lists, and CA chain of trust or cross-certification intelligently, then they do not belong on the governance body for any portion of the NW-HIN. There are enough clinicians, who are capable of meeting those requirements that we have no reason not to expect this level of competence. Moreover, you should fully expect that the governance body will largely ignore your abstract questions and recommendations, and instead focus on those security and privacy issues that bubble up from our protocol choices, and start to ignore those that issues that are largely handled in-protocol.

Regards,
-FT

Like or Dislike: 2  0 (+2)

•What governance activities require a tight hold as a federal responsibility?
•What should be delegated?

If the federal HIT initiative is to remain credible, then Governance must remain tightly controlled at the federal level to the extent that it sets policy and defines the principles for participation.

Validation role:

• Assumptions:
◦ there will be a variety of potential validation approaches, with potential options including but not limited to certification of technology and accreditation of entities;
◦some types of validation may not require formal certification or accreditation, but do need oversight.
◦existing validation entities and processes should be leveraged.
• Should there be an overarching validation entity to accredit other certification and/or accreditation bodies and monitor non-certification/accreditation processes to identify inconsistencies and issues?

Yes there should be an overarching validation entity. Again, without federal control at the top level, credibility of the whole HIT program will not be maintained. Clearly, the actual implementation and day to day operation of certification and accreditation will be most effectively handled by multiple other entites, many of which already exist within and outside government. But unless the federal government takes hand in certifying these various entities as valid certification / accreditation entities for HIT there will be no trust in the overall system.

Coordination/Implementation support role

• Are there critical needs for “what needs to be governed” (from HITPC preliminary recommendations) that require a coordinating/implementation support governance mechanism be established in the near-term?
◦ If so, should this coordination/implementation support role be done by using Federal Advisory Committees, or through public/private or non-governmental approaches?

The federal government are finding what many predicted, that the HIT initiative is going to take a great deal of effort and time to define and develop if it is to be sustainable. The aggressive timelines that the HITPC and its workgroups set are unrealistic if their products are to be of the required quality. Governance is particularly critical to the HIT initiative and it requires patience on the part of the HITPC and the federal government as a whole so that what is developed is valid and workable. Given that, in the shorter term there is a need to put something in place that at least shows the direction in which everthing is and will progress. The federal government must establish an oversight body that will be able to support current efforts being made throught the nation to implement HIT. At the very least, individuals and entities adopting HIT should be able to look for support and advice as to whether what they are implementing is valid in terms of governance structures and privacy and security practices.

Like or Dislike: 2  0 (+2)