A privacy flag would enable data to be automatically routed to specially protected areas of the EHR.Ĥ. 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.ģ. 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. 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.Ģ.

Specifying such a vocabulary is future work.Ī robust discussion followed about privacy flags. or it could be a simple indicator 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. For Privacy we considered many options and recommended a CDA R2 Header with a simple vocabulary to indicate that sensitive data is present. The signature could be an institution, a department, or an individual, as needed by the use case. 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. This XML has nothing healthcare specific such as OIDs in it. For patient ID, we considered many options but selected a very simple XML construct based on a streamlined CDA R2 header.

Stan Huff led the metadata discussion and reviewed the work that has been done to date on patient ID and provenance standards. 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. 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). The notion of creating a standard envelope around data that identifies the patient and the sender of the data enables many transactions. The June HIT Standards Committee meeting followed the 'Summer Camp' schedule precisely, and focused on health information exchange metadata (patient identifiers/provenance/privacy flags), provider directories, patient matching, meaningful use stage 2 standards, quality measures, and feedback how to ease the burden of certification.įarzad Mostashari, National Coordinator, began the meeting by highlighting the importance of taking first steps on early health information exchange use cases.

The hit list 2011 cda.pl