In my recent post about consent policy for HIEs, I reflected that opt in consent to disclose at each institution generating data is patient centric and implementable. One challenge with trying to implement a special “consent to view data at each encounter” workflow for HIV is the difficulty of segmenting the medical record to isolate HIV data. Here’s a sample record that illustrates the problem:
4. BactrimProblem List
2. Sinus Infection
3. HIV positive
I hope you and your partner had a great weekend in Provincetown and that the thrush has improved with the mouthwash sample I gave youWe can create filters for medications that are related to HIV treatment such as AZT. However, some medications are ambiguous. Is the Bactrim being used as prophylaxis against an HIV-related respiratory illness or something else? We see from the problem list that the patient has a UTI, so likely the Bactrim is not HIV related and should be listed as a non-HIV medication. The Letter does not include the words HIV, AIDS, or any medication name. However, it lists Provincetown, which has the highest concentration of same-sex couple households of any zip code in the United States. It mentions thrush which occurs in immunocompromised patients. The Letter could imply HIV positivity.
ONC has launched the data segmentation initiative with the goal of tagging portions of the medical record with enough metadata to separate data into categories that better allow control of information exchange in accordance with patient privacy preferences.
For example, a sample medical record might contain
*Standard care information – problem list, medications, allergies, labs, notes, and immunizations that are not specific to the categories listed below
*Sexually transmitted diseases
*Domestic Violence history
A person’s preference may be to share Standard care information with any care provider, but only share STDs and HIV status with a primary care provider, and only share mental health, substance abuse, and domestic violence history with a mental health provider.
The current state of EHRs and HIEs is that data segmentation is very hard because of ambiguity in categorizing data elements, per the example I gave above. With the ONC data segmentation initiative, implementers will receive guidance so that providers and automated decision support tools can tag data as it is entered, enabling segmentation.
Once data is segmented, we can then record patient privacy preferences for each segment. How do we do that?
Mitre has created an open source patient consent policy management tool called Kairon Consents that is available for use now.
It enables the patient to designate who they want to share data with (e.g., by name, institution, referral relationship to PCP, etc.) and what data they wish to share (e.g. allergies) and for what purposes (treatment, research, etc.).
When a request for data is received, there is a policy reasoner that examines the request and presents the record holder with the relevant patient policies for that request (e.g., “The request is from an allowed physician but only allergy data is allowed to be communicated”.
Clearly this is just the beginning of national-scale consent management tool development, but it is a reasonable platform for initial capabilities and can be scaled for institutional use.
In 2008, I proposed a “Consent Assertion Markup Language“ (CAML). With the Data Segmentation initiative and Kairon Consents, a mechanism for gathering and enforcing more granular patient privacy preferences will soon become a reality.
Dr. H, your wonderfully concise description of the segmentation initiative is also is a splendid case example of the challenges of health data-sharing for the uninitiated. Is there any working model, even a crude facsimile, of the kind of tool(s) you've described? It sounds like you have the blueprint (or the makings of it), but no apparatus as yet. And by 'crude facsimile' I mean something beyond blog applications ;-)