Fhir Data Provenance: Tagging Medical Records For Patient And Ai Contributions
In an era where healthcare data is increasingly sourced from diverse contributors, including patients and artificial intelligence (Ai), the ability to accurately distinguish and manage this information is paramount. New methods are emerging on how patient contributions to medical records can be differentiated from data authored by clinicians. Similarly, recognizing Ai’s role in generating insights is becoming crucial.This article explores the solutions offered within the Fast Healthcare Interoperability Resources (Fhir) standard and its application in healthcare environments.
The General Need For Data Provenance
The fundamental need revolves around expressing the provenance of a Resource or specific elements within that Resource. Two related yet distinct solutions address this need: lightweight tagging and thorough provenance tracking. Sometimes a lightweight solution is sufficient, while other times, a more robust provenance solution is required.
The ability to indicate whether an entire resource or just certain elements were contributed by a patient is crucial.for example:
- A patient’s log of body weights taken at home.
- A patient’s partner providing the patient’s nickname.
- Ai generating a CarePlan based on current lab results, observations, and clinical guidelines.
- Ai creating an Observation interpretation code value.
Tagging Solutions In Fhir
Every Fhir Resource has a ‘.meta.security’ element where tags can be applied to signify the source of the data. When the .meta.security element has the code indicating a patient source, it signifies that the entirety of the resource originated from the patient. Though,this broad-stroke approach may not always suffice. Frequently enough, only a specific element requires such attribution.
Such as, if a patient’s acquaintance provides their nickname, tagging only that element is necessary. The Data Segmentation for Privacy (Ds4P) Implementation Guide (Ig) offers an extension for such scenarios, highlighting that its scope extends beyond mere data segmentation or privacy applications.
Consider a Patient resource where the nickname has been provided by a patient’s acquaintance. In such cases, the inline code must be present at the Resource.meta.security level. This indicates that inline codes are used within the Resource, as these codes can appear on any element, making their detection possibly resource-intensive.
The following is an example of how this is represented:
{
"use": "nickname",
"given": [
"Jimmy"
],
"extension": [
{
"url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
"valueCoding": {
"code": "PACQAST",
"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"display": "patient acquaintance asserted"
}
}
]
}
provenance Solution
Tagging, even at the element level, may fall short of conveying sufficient information. Details such as the identity of the patient’s acquaintance, the time of addition, reasons for inclusion, approval processes, data origin, and its initial usage remain elusive. Provenance addresses these gaps,offering a comprehensive record of who,what,where,when,and why.
While recording all this provenance data can lead to database bloat, the tag mechanism remains focused and fully integrated within the data. However, in scenarios demanding more detailed provenance insights, this approach becomes indispensable.
In Provenance records, the same codes can be applied to various Agents, offering more codeSystem nuance in the participation type. A Provenance record indicating that the entire Observation was contributed by the Patient would appear as follows:
{
"resourceType" : "Provenance",
"id" : "example1",
"target" : [{
"reference" : "Observation/obs2/_history/1"
}],
"recorded" : "2021-12-07T12:23:45+11:00",
"agent" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/codesystem/v3-ParticipationType",
"code" : "INF"
}]
},
"who" : {
"reference" : "Patient/pat3"
}
}]
}
Provenance At The Element Level
The patient nickname example would be represented with the ‘targetElement’ extension. There is also a ‘targetPath’ extension where a path can be used.
{
"resourceType" : "Provenance",
"id" : "example2",
"target" : [{
"extension" : [{
"url" : "http://hl7.org/fhir/StructureDefinition/targetElement",
"valueUri" : "n2"
}],
"reference" : "patient/pat3/_history/1"
}],
"recorded" : "2021-12-08T16:54:24+11:00",
"agent" : [{
"type" : {
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
"code" : "INF"
}]
},
"who" : {
"reference" : "RelatedPerson/f001"
}
}]
}
In Provenance.target, use the extension targetElement or targetPath to indicate that certain data within a Resource was patient-contributed. See examples 1,2,and 3 — in Provenance examples – https://build.fhir.org/provenance-examples.html
| Feature | tagging | Provenance |
|---|---|---|
| Granularity | Resource or Element level | Resource or Element Level |
| Information Depth | Limited | Detailed (Who, What, Where, When, Why) |
| Storage Impact | Lightweight | Potentially High |
| Use Cases | simple Attribution | Complex data History |
Conclusion
The .meta.security and Provenance are not exclusively to be set or used by Security. These values might be populated by a Security Labeling Service (Sls), but that service should not overwrite values that have been explicitly set. Yes,they are used by Security,but security also uses manny other elements in the resources that many think are only useful for clinical use.
the Growing Importance Of Data Provenance
As healthcare becomes more integrated and data-driven, understanding the origin and history of medical information is increasingly critical. The rise of telehealth, remote monitoring, and patient-generated health data (Pghd) has expanded the sources of information used in clinical decision-making.
According to a recent study by Ncbi, accurate data provenance is essential for building trust in Ai-driven healthcare solutions. By tracking the source and transformations of data, healthcare providers can better assess the reliability and validity of Ai-generated insights.
Pro Tip: Implement data provenance solutions early in the development lifecycle of healthcare applications to ensure data integrity and compliance with regulatory requirements.
Faq
-
What is the purpose of FHIR in healthcare?
fhir aims to streamline the exchange of healthcare data between different systems, improving interoperability and data access.
-
how do security labels contribute to data privacy?
Security labels classify data based on sensitivity, enabling appropriate access controls and ensuring compliance with privacy regulations.
-
Can patients control how their data is tagged?
Patients should have the ability to review and potentially control how their data is tagged, aligning with principles of transparency and patient empowerment.
-
What regulations govern the use of patient data in AI?
Regulations such as Hipaa and Gdpr impose strict requirements on the use of patient data in Ai, emphasizing the need for consent, transparency, and data security.
-
How can healthcare providers ensure the accuracy of patient-contributed data?
Healthcare providers can implement validation processes, cross-reference data with other sources, and engage patients in data review to ensure accuracy.
Do you find these tagging and provenance solutions practical for modern healthcare records? share your thoughts or experiences in the comments below!
