Interoperability Roadmap Public Comments

My comment refers to this footnote:

69 While HIPAA required the creation of national identifiers for patients, providers, hospitals and payers in 1996, subsequent legislation prohibited HHS from funding the promulgation or adoption of a national unique patient identifier. Public Law 105–277. 105th Congress. October 21, 1998.

This rider is no longer part of the appropriations language and was replaced with this:

Sec. 510. None of the funds made available in this Act may be used to promulgate or adopt any final standard under section 1173(b) of the Social Security Act providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual's capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard.

As a result, ONC could, for example ask NIST to develop approaches to a national patient id in collaboration with stakeholders with the idea of voluntary adoption of a national protocol.

Most importantly, on the plain face of this new language, ONC can talk about the issue and solicit ideas.

I recognize that ONC wants to insure that it does not run afoul of congressional directives, however this is most certainly a case that needs to be explored. The law has changed and your footnote and practice on this issue needs to do so as well.

The ONC deadline calls for provider implementation by 2017. Now here’s yet another date that will get pushed out and I am sure several times while providers will take the brunt of the beatings for themany delays.
I predict all the delays will be tied to one impossible hurdle, buried deep in the plan that could be eliminated with the wave of a Congressional wand. The big, very big hurdle is creating a real unique patient identifier. The issue is covered in a small footnote on page 69 of the plan. It states:
While HIPAA required the creation of national identifiers for patients, providers, hospitals and payers in 1996, subsequent legislation prohibited HHS from funding the promulgation or adoption of a national unique patient identifier. Public Law 105–277. 105th Congress. October 21, 1998. http://www.gpo.gov/fdsys/pkg/PLAW-105publ277/pdf/PLAW-105publ277.pdf
So there you have it, ONC wants providers to accomplish what Congress refused to deal with and do it through a Rube Goldberg process of virtual and probabilistic methods. And by the way ONC says they will measure via the MU program “provider performance”, e.g., the percent accuracy rate for proper patient identification with the MU penalties if you don’t do it.
Sad story is, if our government was willing to deal with this ID issue head on we could have true interop in six months. After forty years in this industry one thing I have learned is that politics and systems design make terrible bed fellows.

My suggestion is this. If a person wants true health record coast to coast portability they agree to subscribe to a unique ID, if they want to maintain ‘privacy’ they do not. Opt in or Opt out, your choice.
Frank Poggio

Overall ONC plays a key role to help ensure the tools are in place for a connected ecosystem. Work to attain semantic interoperability should continue to be a high priority.

However, three primary concerns with the current Roadmap.

1) Not including the administrative (billing) with the clinical will not bend the cost curve, which was pivitol aspect to the HITECH ACT funding and support from organizations I worked with to generate the necessary evidence for Congressional support, such as the 2007-2008 HIMSS HIT Task Force http://www.himss.org/files/HIMSSorg/policy/d/Approp_letter_Steve_Lieber…

2) Recognize that the "Internet as we know it" is erroneous thinking. It is actually changing. Technological advancements will continue to outpace policy and to build ATM networks will actually place patient clinical data at HIGHER security and privacy risk.

3) Data. Unlike other technical solutions, Health Information Technology pivots around the data. From semantic interoperability and the consistent meaning through the clinical process, to the format of messages and packets transmitted via the internet. The term "data" has multi-facets, and thus security and privacy is multi-faceted. Limiting the focus to clinical use cases,encryption, and API calls, will only exasperate the current security issues.

4) Chronic health care is fundamentally different from Acute, in that 90% is dependent on patient behavior during their personal daily activities. An ATM network between hospitals not only fails to protect, but actually leaves 90% of patients data in the clear. However, if the ATM network includes the sw developer cloud "kits", then Government begins to take a very dangerous role to control who has access to innovate mobile technology platforms. Neither is a benefit to the US patient population or health care system.

Please see my more extensive comments http://bit.ly/1zsnUn7

Fantastic, well thought out, very well planned, and a great foundation for where the industry is within VNA implementations. We need to break the existing vendor lock within healthcare and look to Platform, Bus based, SOA implementations. It brings forward the issues Healthcare Organizations will see inside their current EMR implementations. The HCOs should be mad in what they really bought for billions of dollars. What I like the most is the focus on the horizontal view of the Patient and Patient outcomes vs vendor specific product silos. Nice Job! Now HCOs must demand standards based implementations, vendor change, and most certainly interoperability from their vendors. I would like to propose one additional section. That based on hardware and software abstraction for purposes of removing the migration pain points. 1) Physical migrations: disk to disk, server to server 2) Application migrations: every 8 years or so the applications are moved or you preserve the application for decades or the life of its data content. 3) Data Tech Refresh: as the content stored ages, it needs a refresh to post to new evolving applications.

PLEASE EXEMPT small private practices in psychotherapy from interoperability.
I have been a SOLO practitioner for 24 years. I RARELY get requests for records, and when I do, I safely mail them through the USPS or I fax them.
it would be cost prohibitive and risky for sensitive information if I had to have an HIE. There are too many unknowns. Like would I have to pay for storage in the Cloud after I retire?
There are hospitals who don't even have HIE now between doctors and nurses!

I believe the vaccine program in the U.S. in both the private and public sector serves as a potential model to improve interoperability and functionality. Interoperability could interface both current EMRs with state vaccine registries and also provide a platform for sharing vaccine records between states. With each state having different software, access to records between states is currently not possible. Functionality is missing in the majority of EMRs when it comes to vaccine management. There is often a "basic" module however documentation is cumbersome and prone to error. By not automating workflow, nurses spend inordinate amounts of time in inventory, administration, documentation and ordering vaccines. The VFC program providing vaccines to children with Medicaid and the uninsured has been abandoned by many providers due to time consuming regulations and audits as well as poor reimbursement.

http://pediatrics.aappublications.org/content/early/2014/12/23/peds.201…

This effort needs a call hotline so people can not only email views and ideas but talk with someone in the know.
There is too much confusion, loose ends out there to chase to get a simple answer to a simple question.

A process needs to be established that permits technical errata changes and minor technical improvements to be folded into a specification which has been named in legislation. For example, if a specification such as HL7 Consolidated CDA (C-CDA) R1.1 is cited as a standard, then it needs to be possible for minor technical revisions to this specification to fulfill the requirement. When the SDO governing the specification releases a minor revision, such as C-CDA R1.1.1 or R1.1.2. By allowing minor technical revisions to be identified and accepted, it will be easier for improvements to be introduced and managed.

Privacy and security for individuals: In doing some reading about the development of standards for Hl7's FHIR and Blue Button, I have come across developer comments where privacy and security issues seem to be taking a back seat to developer's preferences for ease of development. Some comments concerned the use of Etags, which have been associated with tracking of individuals on the internet. Here is the exact quote that I found at http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&t…:
"The normal way to do this in other RESTful APIs is to use etags. Early drafts of FHIR used eTags, but this was removed because of privacy concerns that had been identified. However these have not meant that eTag usage has been replaced, and the eTag approach is better - (see comments thread here: http://hl7.org/implement/standards/fhir/http.html#comment-1535338227)
We should replace this content-location approach with the standard e-tag appraoch (even if it's not consistent with the OMG RLUS spec - that should change too)."

Etags have been found to be able to track individual users on the internet. From wikipedia,http://en.wikipedia.org/wiki/HTTP_ETag#Tracking_using_ETags.

"ETags can be used to track unique users,[2] as HTTP cookies are increasingly being deleted by privacy-aware users. In July 2011, Ashkan Soltani and a team of researchers at UC Berkeley reported that a number of websites, including Hulu.com, were using ETags for tracking purposes.[3] Hulu and KISSmetrics have both ceased "respawning" as of 29 July 2011,[4] as KISSmetrics and over 20 of its clients are facing a class-action lawsuit over the use of "undeletable" tracking cookies partially involving the use of ETags.[5]

Because ETags are cached by the browser, and returned with subsequent requests for the same resource, a tracking server can simply repeat any ETag received from the browser to ensure an assigned ETag persists indefinitely (in a similar way to persistent cookies). Additional caching headers can also enhance the preservation of ETag data.[6]."

Yet, the developers of the FHIR standards have decided to go ahead and use them. This seems to completely defeat the goal of providing a secure way for users to view their health care data from home on a computer.

In addition, comments were also made concerning the security risks involved in passing parameters in a query when using the Restful API with FHIR. Here is a link to the page, the comments are at the end of the page. http://www.hl7.org/implement/standards/fhir/http.html

Vince Guaglione makes the following comment: "In looking at this API, I see that many of these interactions require parameters to be passed on the query string. However, some of this data would be considered PHI and I'm curious why FHIR would allow this. Best practice is that sensitive data shouldn't be placed in the query string because there's no guarantee the query string is completely safe, even when SSL encryption is used. For my organization, this is a huge sticking point."

Another person replies that this is simply the risk of using query parameters.

It seems as though the developers are not taking as seriously as they should the sensitive nature of the data - and the fact that individual's healthcare data will be transferred across the internet where there doesn't seem to be very much security in the first place.
What kind of oversight is there at this level of development to ensure that the platforms used and the development of programs is using the best technology for securing the privacy of healthcare data in addition to protected health information. The developers also don't seem to understand in the above example concerning query parameters that protected health information includes individual's name, address, birth date, and identifying information. One developer states that "resource identifiers are essentially system keys and I don't think would qualify as such" (as PHI- protected health information). I think HIPAA has a different outlook on this.
I think that before the interoperability goals can be met, more research needs to be done on how to secure data across the internet as the current technologies don't seem to be able to do this.
I would hope that developers are working directly with HIPAA privacy experts when developing standards and computer technologies and that these new products are reviewed by developers for weaknesses that can lead to users being tracked or having their data stolen.

Please see uploaded document, thank you.