Letter to HHS Regarding Nationwide Electronic Health Information Exchange
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.
- 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.
