Farzad Mostashari, National Coordinator, began the meeting by highlighting the importance of taking first steps on early health information exchange use cases. The notion of creating a standard envelope around data that identifies the patient and the sender of the data enables many transactions. Supporting privacy flags enables the recipient of the data to obtain necessary consents before viewing data and to store the data optimally to respect patient privacy preferences (such as special locked areas for mental health, substance abuse or HIV related data). Privacy flags may not be needed if the patient is the source of the data or the patient gives consent to disclose and consent to view directly to the provider at the point of care.
Stan Huff led the metadata discussion and reviewed the work that has been done to date on patient ID and provenance standards. For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header. This XML has nothing healthcare specific such as OIDs in it. For provenance, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header and X.509 certificates for digital signature. The signature could be an institution, a department, or an individual, as needed by the use case. For Privacy we considered many options and recommended a CDA R2 Header with a simple vocabulary to indicate that sensitive data is present. The list of sensitive data types could include mental illness, substance abuse, sexually transmitted disease data, HIV data, domestic violence data etc. or it could be a simple indicator that sensitive data is present. Specifying such a vocabulary is future work.
A robust discussion followed about privacy flags. Here are important clarifications
1. During transmission, the envelope of metadata plus the payload of content is fully encrypted and so the metadata is not readable until it arrives inside the organization or to the person authorized to read it.
2. Much of the time, no privacy flags are needed because the patient will be the source of the data and will elect what to disclose to whom. Privacy flags would likely be needed when data is assembled from multiple sources and is received by a provider who needs to obtain special consent before viewing it or apply special protections before storing it.
3. A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.
4. The CDA R2 header standards are used millions of times per day throughout the world but this subset of them and constrained specifications of how/when they are used should be tested before regulations require them for specific transactions.
5. The recommendation to use CDA R2 headers for metadata is the beginning of a formal ONC process to seek comment, feedback and stakeholder engagement regarding their use.
Based on all these clarifications, the HIT STandards Committee approved the use CDA R2 header for metadata as a formal recommendation to ONC as it begins the NPRM process.
Next, Dixie Baker and Walter Suarez presented Provider Directory recommendations. At last month's meeting, they suggested the use of LDAP/IHE HPD standards and received feedback that these standards were not the best fit for cross organizational/federated directory lookup. They reconsidered the possibilities and examined DNS as a means to find IP addresses and certificates, the concept of a Top-Level-Domain as a means to create a uniform, secure way to retrieve directory information about healthcare organizations (of note, ICAAN announced that such Top Level Domains will soon be very easy to create), and the use of microformats/microdata as a means of creating simple federated lookups for provider directory information that cannot be stored in DNS, such as street address and phone number. Web pages containing such data can be secured with Extended Validation certificates to provide identity verification of the entity publishing the information i.e. it really is Beth Israel Deaconess publishing the directory information about Beth Israel Deaconess. Summarizing their recommendations for provider directories:
1. DNS should be used for certificate retrieval per the Direct Specification plus web pages with microformats/microdata should be used for additional directory information. These web pages can be federated via standard search engine technology.
2. A Top level domain can be considered in the future, but there is no need to implement one now.
The HIT Standards Committee approved this recommendation as input to the S&I framework process.
Next, Doug Fridsma let a discussion of progress on "Summer Camp".
Marc Overhage presented the work on patient matching, noting that the work of the group is to specify those data elements that can be used to match patients, achieving a reasonable balance of sensitivity and specificity i.e. it's ok to occasionally not find a patient's record, but it is very bad to find the wrong record. The team is not specifying the matching algorithm such as exact match, probabilistic match, partial match (first six letters of last name), Soundex or other approaches. Their work to date suggests using patient name, gender, date of birth and numeric identifiers (such as driver's license number, payer member number, last 4 of SSN etc.). It does not preclude the possibility that new identifiers such as an opt in patient healthcare ID, a DIRECT address, or other identifier could be included in the future.
Dixe Baker presented an overview of the Nationwide Health Information Network power team effort which will create a set of building blocks encompassing all the requirements of the existing NwHIN Exchange standards and Direct standards. Their final report will be presented in September.
Steve Posnack presented the Standards and Certification Criteria codeset update that enables the latest version of SNOMED-CT, LOINC and CVX to be included in Certification testing.
George Hripcsak and Josh Seidman presented an overview of Meaningful Use Stage 2. In the next few weeks, ONC will determine what gaps need to be filled with new standards specifications.
Jim Walker presented the Clinical Quality Workgroup Update as the group continues to simplify the computation of measures and reduce the level of effort to comply with the quality reporting requirements of meaningful use.
Judy Murphy and Liz Johnson presented the Implementation Workgroup Update. They are completing data gathering and analysis of feedback on the certification process and ways in which it can be improved for stage 2.
A very productive meeting. I look forward to the July meeting and the work ahead on Meaningful Use Stage 2 standards.
I have suggested that the S&I Framework Provider Directory sprint group follow what is being proposed in the Standards Committee for the purposes of harmonization.
ReplyDeleteAt the same time, I don't agree with the re-contextualization of X.500 and LDAP since it's logically the simplest and most scalable Internet solution using TC 215 Health Informatics data elements.
DNS will not scale to the same extent. Microdata, may be useful for helping search engines import structured data as part of their content business models, but the schema in the X.500/LDAP national Directory will be far more relevant to existing stakeholders, including Certificates, and a direct address, as defined by organizations themselves who already have this in place, in Active Directory, LDAP, etc.
John, your minutes are so timely ahd helpful. Not only that, but your comments during the meetings are thoughtful and made in a positive spirit. Thank you.
ReplyDeleteI do question something in this post, though. OID-bashing seems to be popular in the HIT SC. While I acknowledge that OIDs are difficult to read, they're also internationalized, language-neutral, and not healthcare-specific. http://en.wikipedia.org/wiki/Object_identifier describes their origin in International Telecommunications Union and ISO. Just because HL7 uses them doesn't make them unique to healthcare. They are used in other industry-neutral standards (e.g., X.509 digital certificates, X.500 directories) some of which are being advocated by the same HIT SC!
If OIDs aren't chosen for the metadata, that's up to the committen, but the reason given should not be because HIT SC wants to use "internet standards" or "non-healthcare-specific standards."
Thanks again for your leadership.
I am very glad that you are leading this effort and I appreciate that you publish these summaries from your point of view. I am concerned that there is so much experience in Healthcare and Internet space that is being ignored. I certainly hope this is not intentional, but it is painful anyhow.
ReplyDeletea) please don't reinvent data classification, it is a very mature part of IT Security http://healthcaresecprivacy.blogspot.com/2010/08/data-classification-key-vector-through.html
b) Data Classification is just one vector. Just like User-Role is just one vector. Access Control inclusive of Privacy considers them all. http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf
c) Complex Consent does not need to be NwHIN portable. Enforce it at the Data-Source, no need to tell Data-User why they don't get access.
d) Once Data-Source determines data can be disclosed; control of the copy becomes Data-User responsibility.
Regarding Provider Directories:
e) the HITSC should not be making the Policy decision on 'who' or 'how' one decides to trust. Certificates are self-validating, the infrastructure does not need to add this complexity (risk of failure). Organizations will make different decisions on who to trust, and for what they trust them to do.
f) I was listening closely and there was disagreement about this new model. I know you like it, but it has some real questionable operational issues. Now it has been presented to S&I today by Dixie as a solid mandatory solution to replace LDAP recommendation.
g) Please explain how Google/Bing/Yahoo is an authority on Healthcare, but IHE/HL7/DICOM are not?
Metadata
h) CDA is not an envelope, it is a document. XDS Metadata is a generic envelop that can carry MANY document types of documents including DICOM and CCR. Why was it not considered? I understand that there are people that misunderstand XDS as being restricted.. it's only restriction is to a document that has a MIME-TYPE. the XDS Metadata is specifically designed to be content agnostic, yet derived from CDA as a mature model.
i) experience with CDA and XDS is available at http://tinyurl.com/wwxds . This experience is EXTENSIVE. It should NOT be ignored. If it there is a good reason for it to be ignored, please explain.
Patient Identity Matching
j) Matching Consumers credit reporting in the financial industry has lots of false positive/negative; but their failures don't hurt/dismember/kill.
k) Please look at XCPD. It has included much input from many global subject matter experts, including Voluntary Patient ID. It is primarily the work of those involved in NwHIN.
Also:
I agree with the comments from dining_phil and David
John,
ReplyDeleteWill there be emissaries and a feedback loop to bridge between the HIT SC's "microformats/search" recommendation for PD to the ONC S&I framework? That could help, so that there aren't disconnects in assumptions and objectives. (That kind of thing also happened for a while with the Direct Project). While everyone is familiar with web search, the concept of using it for PD seems to be controversial as to its reliability and precision, given that it seems to lack validation of the content. Would there be conformance tests, certification? As we know, existence of a standard is no assurance that thousands of organizations all implemented it consistently. From a user perspective, would I just type "John Halamka BIDMC" into Google and find you accurately? What about "John Smith, Mass Ave, Boston?" How would EHRs interoperate with it? Certainly it appears simple. Would it meet the requirements? Can that really be known at this point? People participating in the PD initiative will want to understand this in much more depth than available in the info published thus far.
Can someone answer why are we even brothering with the S&I Framework Provider Directory effort to identify use case requirements when it looks like the HITSC and Privacy & Security workgroups are chosing standards?
ReplyDeleteThe HITSC Privacy and Security Workgroup has submitted input to the S&I Framework process and not selected provider directory standards. The provider directory report was not a set of formal recommendations to ONC for rulemaking, as was done for metadata.
ReplyDeleteYour latest comment is NOT consistent with how the DECISION was presented to the S&I Framework PD sprint committee. It was presented as a final decision to reject LDAP and force the use of microformats and google/bing (ok, not that strong, but I know some took it that way). I LIKE your comment, and would really like it to be clarified to the S&I Framework. I WANT the microformat, and hCard, and vCard to be given just as much chance as DNS, LDAP, and HL7 v3… an open and transparent evaluation is all I ask for.
ReplyDeleteAs I explained at the June HIT Standards Committee meeting, the Committee takes two kind of actions
ReplyDelete1. Making recommendations to ONC as input to rulemaking. It does this very rarely because ONC then has to act using specific processes and timelines. At the June meeting, the Committee was asked for forward its Metadata recommendations to ONC for rulemaking.
2. Offering input to the S&I Framework process including suggested standards, constrains, and guidance as to which standards are good enough, which need work and which need to be created from scratch. The Provider Directory work was forwarded to the S&I Framework as input, not as recommendations for rulemaking. I just signed the letter.
As Coordinator of the S&I Framework Provider Directories (PD) initiative, I want to echo John Halamka's comment: the feedback from the Standards Committee does not constitute a mandate to the PD initiative to explore a specific family of standards only - rather it serves as input into our open, transparent and community-driven process. Through this process, we will evaluate the range of standards (LDAP, DNS, microformats, and other potential candidates) to address the use cases and success criteria that the community agrees upon.
ReplyDeleteAlso, not to turn John's blog into a billboard, but we're all aware that there have been some bumps in the road as we figure out how best to incorporate the feedback from the Standards Committee to the S&I Framework, particularly with respect to this initiative - so stay tuned for updates and opportunities to gain further clarity. (I can also personally be reached anytime at jitin.asnaani@siframework.org).