Letter to HHS Regarding Nationwide Electronic Health Information Exchange

September 23, 2011 Categories: Comments and Letters, Regulatory Issues


September 23, 2011

Department of Health & Human Services
Office of the National Coordinator for Health Information Technology
Attention: Stephen Posnack Hubert H. Humphrey
Building 200 Independence Avenue, SW Suite 729D
Washington, DC  20201

Re: Metadata Standards to Support Nationwide Electronic Health Information Exchange

Dear Mr. Posnack:

On behalf of the American Clinical Laboratory Association (“ACLA”), I am pleased to provide these comments on the Office of the National Coordinator for Health Information Technology’s (“ONC”) Advanced Notice of Proposed Rulemaking (“ANPRM”) on “Metadata Standards to support nationwide electronic health information exchange.” ACLA is an association representing clinical laboratories throughout the country, including local, regional and national laboratories. As the primary providers of clinical laboratory services throughout the country, ACLA members would be directly affected by ONC’s proposals concerning metadata.

I.    Overview.

Before turning to the specific questions raised by the ANPRM, we wish to emphasize several key points at the outset. The ANPRM requests input concerning the goal of implementing metadata standards in connection with electronic health records. ACLA strongly encourages ONC to carefully consider whether it is reasonable and appropriate to impose the additional requirements related to metadata standards at this time. There would be significant costs to adding the additional layer of complexity represented by metadata standards to current requirements. Moreover, as indirect providers, who typically do not have direct contact with the patient, laboratories would have a particularly difficult time implementing many of the standards suggested by the ANPRM because we simply would not have the data required. Finally, and perhaps most significantly, laboratories, like all health providers today, are currently  struggling to complete a number of other new HIT initiatives, including the transition to the new Version  5010  and  ICD-10  diagnosis  coding  standards,  each  of  which  requires  a significant expense of time and money to put in place. As a result, we seriously question whether this is the right time to impose new, and costly, metadata standards.

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.

For the proposed use case of a patient downloading information from an EHR, it does not seem necessary to include alternative addresses in the patient’s PHR.

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.

14. Assuming that we were to require that EHR technology be capable of meeting the first-use case identfled by the HIT Policy Committee, how much more difficult would it be to design EHR technology to assign metadata in other electronic exchange scenarios in order to support meaningful use Stage 2. Please identify any difficulties and the specIc electronic exchange.

As noted above, ACLA strongly recommends restricting any new metadata requirements to the initial use case for meaningful use  Stage  2.  Expanding beyond this current use case would require resolution of numerous  additional issues, some of which are highlighted in the ANPRM itself. It seems far more appropriate to test the metadata concept with regard to the initial case use proposed by the ANPRM before applying it to other situations. Such an approach will give all parties an opportunity to resolve the issues that may arise before expanding to a larger set of scenarios.

17. In addition to the metädata standards and data elements we are considering, what other implementation factors or contacts should be considered as we think about implementation specIications for these metadata standards.

We recommend the ONC clearly define expectations and requirements for managing changes, such as name changes, over time. For example, do patient privacy preferences only impact data prospectively and not retrospectively with regard to data already exchanged with other providers or downstream systems? Further, we urge the ONC to consider in particular the impact of metadata requirements on indirect providers such as laboratories that  have  minimal interaction with patients.  Finally, with respect to standards and implementation specifications, it is critical to ensure that downstream changes in data are not attributed to the original data source unless the original data source  made  the change.

We hope you find this information useful.  If you have any questions, please do not hesitate to contact us.


See the original PDF here.


Print page / Save as PDF