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:
Medications
1. Tylenol
2. Sudafed
3. AZT
4. Bactrim
Problem List
1. Headache
2. Sinus Infection
3. HIV positive
4. UTI
Letter
I hope you and your partner had a great weekend in Provincetown and that the thrush has improved with the mouthwash sample I gave you
We 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
*Mental Health
*Sexually transmitted diseases
*Substance abuse
*Domestic Violence history
*HIV status
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.
Good job again. The hard part is the first part. This part should NOT be in the hands of security or privacy experts. This part should be in the hands of the experts in the clinical information and knowledge. I look to CDS to automate that clinical knowledge some day. When CDS is good enough to provide perfect diagnosis and treatment; then I think we can trust it to segment data perfectly. Until then we struggle with imperfect solutions.
ReplyDeleteHi Dr. Halamka,
ReplyDeleteThat was a great new for a morning Monday!
The data segmentation initiative and the adoption of the open source patient consent policy management tool, together, can improve the exchange of clinical data between states. If the ONC requires these tools as criteria for HIE, this initiative can make nationwide health exchanging information much easier.
Thanks,
Vanessa Sarmiento
Can it be assumed that emergency room providers would always be able to "break the glass" so that they have access to all of the medical information necessary to make informed decisions? Or would patients be able to limit the information to which emergency room providers have access with the understanding that their care could be compromised during an emergency?
ReplyDeleteIs data segmentation a result of PCAST recommendations one year ago? More specifically, are we moving towards a universal exchange language and a different HIE model in the US? Thanks.....Bob Hoyt
ReplyDeleteJust an FYI: Microsoft introduced a XML-based markup language that goes by the acronym CAML with their SharePoint collaboration platform several years ago. See this MSDN Library page:
ReplyDeletehttp://msdn.microsoft.com/en-us/library/dd588092(v=office.11).aspx
Bob Hoyt,
ReplyDeleteThe data segmentation problem (not to be confused with a solution) that is implied by selective access to patient data has been broadly understood by many people for a long time — long before the PCAST report, I'd wager.
On your second question, see Keith Boone's blog posts tagged with PCAST, especially the most recent one.
Thanks very much for the mention, Dr. Halamka. As the PI for the Kairon project, I can address the question about break the glass, there is a built in feature to manage that. Note that Peter Mork, PhD and Arnon Rosenthal, PhD, were the primary technologists for the project.
ReplyDeleteThere is also a feature to manage mandatory sharing (e.g. communicable disease reporting) and a feature to allow what we call "patient-in-the-middle". The patient could use that feature to insist on approving any request for data access. We see that being important in cases where the patient may be involved in a spousal abuse situation or for celebrities.
Regards,
Jean Stanford
MITRE
jstanford@mitre.org
It should be mentioned that the association between the medications the patient is taking, and the problems on their problem list, is explicitly modeled and maintained in a truly problem-oriented medical record. In fact, this can be said of almost all the data in a properly maintained POMR.
ReplyDeleteHardly any current generation EHRs are maintained in a problem-oriented fashion, even in those cases where the underlying database schema supports it (usually just in part). Indeed, problem lists are for the most part poorly maintained, to the point where major medical informatics centers like the Brigham are studying techniques for semi-automatically inferring candidates for inclusion on the problem list from other data in the record — even free text notes. (See the March 1 JAMIA webinar on the subject.)
It is a bit ironic that the lack of problem-orientation is turning out to be a problem for implementing segmented access to patient data to honor privacy policies on EMRs, to say nothing of the ways in which it limits the clinical value of the record for those who do have access to the data. One can imagine that this will have to be dealt with in the fairly near future, if the expectations of modern EHRs are to be met.
Following up on Chris W's comment, some readers may not be familiar with the problem-oriented medical record (POMR). First developed in the 1950s, the POMR is a standard of care for organizing data in medical records. Two core elements of the POMR standard are (1) the problem list, and (2) linkage of the problem list with other elements of the record. This linkage requires practitioners to associate plans and progress notes (including orders, test results, observations and assessments) with specific problems on the problem list. In addition, the POMR standard requires a logical structure within plans and progress notes for entering data. Organizing records in this way is important for clinical purposes, including care coordination, quality improvement and patient engagement. As a byproduct, the POMR standard removes "the ambiguity in categorizing data elements" that Dr. Halamka identified as an obstacle to data segmentation for privacy purpose.
ReplyDeleteThe POMR standard is one part of a larger set of tools and standards and institutional reforms for building a system of care. Interested readers should see last year's book, Medicine in Denial, http://www.createspace.com/3508751, from the original developer of the POMR standard, Dr. Larry Weed (my father). A link to the book's table of contents, overview and introduction is available at http://xnet.kp.org/permanentejournal/sum09/Lawrence_Weed.html. See also our comments on the PCAST report, arguing that metadata should be used to tag data elements by their place in the the POMR structure, http://www.regulations.gov/#!documentDetail;D=HHS-OS-2010-0030-0099.