If, nonetheless, ONC decides to continue with this initiative, then ONC should limit the use of metadata to the single use case selected by the HIT Policy Committee and discussed in the ANPRM; i.e., the situation where a patient downloads a summary record from a health provider’s EHR technology (which, as ACLA has noted in prior comments, should be expressly defined to exclude Laboratory information systems, which are not EHRs) or requests that it be transmitted to the patient’s PHR. This single application, which as defined would likely still have some impact on laboratories due to demands of physician and hospital clients, should be the only the test case for the use of metadata. It would be inappropriate to expand these requirements to other situations before there had been an opportunity to measure the impact in a more limited situation.

II.           Responses to Specific Questions.

We turn now to some of the specific questions raised in the ANPRM.

Patient Identity Metadata  Standards.

1. Are there additional metadata elements within the patient identity category that we should consider including? If so, why, and what purpose would the additional element or elements serve?  Should any of the elements listed above be removed? If so, why?

First, it is important to clarify whether the various patient identity attributes are mandatory or optional. In many instances, records can be successfully created in a Patient Management System (PMS) or Electronic Health Record (EHR) system without some of these attributes. Making all of the listed attributes mandatory would greatly interfere with clinical workflow.

In addition, we believe that the ONC should delay a requirement for support of previous names\associated date ranges until future meaningful use stages. These elements are not currently provided to laboratories, and the data is not necessary for the use case where the patient is downloading his or her own summary care record. It would be premature to require those affected by this proposal to have to create systems to obtain, maintain, track, and disseminate this metadata. In addition, we believe that most of the questions raised in this  inquiry are better delayed for a future phase of meaningful use requirements, as they are not crucial for the use case at issue here.

Further, with regard to uses of zip codes, the ANPRM indicates that zip codes for other addresses are optional and should include date ranges. We ask that the ONC clarify whether or not this means that the associated address is also optional.

ONC should also consider the following issues with regard to the questions raised.

• The ONC should consider how to specify the format for date of birth.

This could be done in either of the following ways:    MMDDCCYY or CCYYMMDD, etc. (with Mmonth, D=day, C=century, Y=year).

• The ONC should consider how to specify last names that have two components (e.g., Van Winkle). Will these  be handled in two separate fields, a single last name field with or without a space?
• ACLA also recommends removing driver’s licenses due to privacy concerns and issues related to identity theft.

2.           In cases where  individuals lack address  information,  would  it be appropriate  to require that the current health care institution’s address be used?

Again, it seems unnecessary to address this issue as part of the current case use proposal, where a patient is downloading his or her own  information  from  an EHR system. Furthermore, we are concerned that using  the  health  care institution’s address would introduce confusion into the records, remove an important identifier, and could lead to false or inappropriate patient matching and data aggregation in some cases.

3.           How difficult would it be today to include a “display name” metadata element? Should a different approach be considered to accommodate the differences among cultural naming conventions?

Again, we believe this is an issue that can be considered for future meaningful use stages, but question whether it is necessary for the current use case.

General Comment 

Details  regarding  the  ownership  and  origin  of  data  elements  need  further clarification.     Does ownership need to be identified for specific sections, each entry within a section, or on some other basis?  Is ownership required for some sections and optional for others?  If information is an aggregation from multiple sources (i.e. data was queried and retrieved from a health information exchange that aggregated the information from multiple sources) is there an expectation that provenance data would be supplied by each of the source systems and propagated by  each  downstream  system?  This  would  pose  technical  and  functional challenges for originating systems, which may not have access to provenance data, as well as receiving systems which do not maintain provenance data at either a course or fine grained level.

 5.     With respect to the provenance metadata elements for time stamp, actor, and actor ‘saffiliation, would it be more appropriate to require that those elements be expressed in XML syntax instead of relying on their inclusion in a digital certificate? For example, time stamp could express when the document to which the metadata pertain was created as opposed to when the content was digitally signed.    Because this approach would decouple the provenance metadata from spec/Ic security architecture, would its advantages outweigh those of digital certificates?

Regarding provenance metadata elements for time stamp, actor, and actor’s affiliation, if required, it would be more appropriate to require those elements be expressed in XML syntax instead of relying on their inclusion in a digital certificate. The generation of digital certificates for locally owned data, as well as the management of and access to digital certificates for data owned by external systems, would require significant functional and technical changes to lab and EHR systems. In addition, standards regarding digital certificate generation, management and accessibility have not been clearly defined at this point. Simply defining and implementing these standards will be challenging and difficult to achieve by the time that meaningful use phase 2 must be achieved.

6.    Are there additional metadata elements within the privacy category that  we should consider including? If so, why, and what purpose would the additional element’s serve? Should any of the  elements  listed above  be removed?  If so, why?

ACLA members are particularly concerned about any metadata requirements related to patient privacy preferences. Laboratories have minimal contact with patients, and therefore it would be difficult for them to know of, and tag, specific patient privacy preferences in connection with such data. Moreover, even if the data tagging was accomplished through middleware  or some other methodology not involving intervention by the clinical laboratory, it is possible that data exchanges to and from clinical laboratories that are legally permissible or required could be blocked. Many unintentional  and  harmful  consequences  could potentially  result.

Moreover, ACLA members are particularly concerned about what will happen if a patient changes his or her patient privacy preferences. For example, if a laboratory or provider shares information at one point in time, but a patient subsequently  changes  his privacy  preferences,  how  will  that  information  be communicated? What will the expectation be with regard to data that  had previously been exchanged under the old standard? Further, if a patient provides such information to his or her physician, how is that information likely to be communicated to other indirect providers such as laboratories? Also, if patient provides that information to a laboratory, to what extent should that information be provided by the laboratory to other providers — particularly with regard to previous disclosures.

The level of granularity associated with assigning privacy data needs additional clarification. Similar to what was stated above regarding provenance data, if information presented is an aggregation from multiple sources (i.e. data was queried and retrieved from a health information exchange that aggregated the information from multiple sources) is there an expectation that privacy data would be supplied by each of the source systems and propagated/persisted by each downstream system? If this is the case, it would require significant functional and technical changes by both originating and aggregating systems.

8. Is a policy pointer  metadata element a concept that is mature enough to include as part of the metadata standards we are considering?  More  specflcally,  we request comment on issues related to the persistence of URLs that would point to privacy policies  (i.e., what f the  URL changes over time) and the implication of changes in privacy policies  over time (i.e., how would new policy  available at the URL apply to data that was transmitted at an earlier date under tan older policy that was available at the same URL)?

EHR systems maintain some high level  privacy  and  consent  information pertaining to local data, but it is not typically maintained at a fine grained level (medications, allergies, problem list, etc.). In  addition,  very  little  experience exists in utilizing external privacy pointers particularly outside the realm  of  a limited number of health information exchanges. The existence of repositories to support privacy pointers is not prevalent and the standards are not widely adopted at this time. The standards associated with this type of information would need to be more clearly specified and the concepts associated with  these  repositories would need to be more mature  before  EHR  systems could effectively  integrate this functionality into their products.

11.The HIT Standards Committee recommended developing  and  using coded values for sensitivity to indicate  that the tagged data may require special handling per establish policy…. Does a widely used/commonly agreed to value set already exist for  sensitivity that we should be considering using?

Additional clarification on the concept of ‘sensitivity’ of the data is needed.  How are individuals or receiving systems identified or classified for determining the level of access to data? Similarly, what are the categories or restriction levels associated with what can be done with the data? Management of this type of data could become extremely complicated and superfluous, resulting in complications from both a system implementation and workflow standpoint.