Last December the President’s Council of Advisors on Science and Technology (PCAST) issued a report that suggested a new approach to health system interoperability that involves breaking medical records into data elements. Each element would have attached “metadata” information describing it and allowing it to be searched the way a search engine searches website data.
At the time, that proposal drew a fairly cool response from the industry establishment. HIMSS’ comment to the Office of the National Coordinator for Health IT (ONC) said, “We believe that the PCAST approach could lead to substantial and negative disruptions that will impose clinical and financial costs that are not offset by reasonably foreseeable benefits.”
Yet ONC has taken the PCAST suggestion seriously. It has just issued an advance notice of proposed rulemaking on metadata standards recommended by the Health IT Standards Committee. It proposes using HL7’s CDA R2, a document markup standard that specifies the structure and semantics of a clinical document for the purpose of exchange.
According to ONC, the metadata standards under consideration involve:
• Patient Identity Metadata – These metadata relate to patient identity and include: a patient’s name; date of birth; address; zip code; and relevant patient identifier(s).
• Provenance Metadata – These metadata would be used to provide information on the “who, what, where, and when.” Provenance metadata would include: a tagged data element (TDE) identifier; a time stamp; the actor; and the actor’s affiliation.
• Privacy Metadata – Privacy metadata would include a policy pointer and content elements descriptions such as data type (e.g., consultation note) and sensitivity.
Following the June HIT Standards Committee meeting, John Halamka, M.D., CIO of Beth Israel Deaconess Medical Center and vice chair of the HIT Standards Committee, made these observations on his blog about privacy metadata considerations:
• 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.
• 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.
• A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.
• 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.
• 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.
John Halamka, M.D.
ONC will accept public comments on the proposed rulemaking until Sept. 23, 2011.