Sustaining the Work That Sustains Trust: Why I’m Seeking Support for Some of My Standards Efforts

For many years, I’ve used this blog to explore the intersection of healthcare, privacy, and interoperability. Much of my professional life has been dedicated to helping the industry build systems that respect patient autonomy, protect sensitive information, and communicate clearly across organizational and technical boundaries.

Recently, I launched Moehrke Research, my independent consulting practice. It’s still early in its development, but it reflects the same principles that have guided my work for decades: clarity, transparency, and a commitment to practical, implementable standards. As I grow this business, I’m also continuing to invest deeply in common-goods efforts that advance the broader ecosystem.

Right now, that includes two areas that are both urgent and foundational:

• AI transparency in healthcare, through my pro bono work on the HL7 AI Transparency Implementation Guide
• Privacy‑sensitive data handling, through contributions to the SHIFT Task Force and the HL7 Sensitivity IG (a specialization of HL7 DS4P)

These efforts are essential to the future of trustworthy digital health. They also require a significant investment of time—time that I’ve been donating because I believe deeply in the work and in the communities that will benefit from it.

But the reality is that these projects have grown in scope and complexity. They now demand sustained, focused attention to ensure they mature into practical, implementable guidance that organizations can rely on. And that level of commitment is difficult to maintain without dedicated support.

Why This Work Matters

Healthcare is entering a period where AI‑generated content, automated decision support, and increasingly granular privacy expectations are no longer theoretical. They are here, influencing care, shaping patient experiences, and challenging long‑standing assumptions about data governance.

The AI Transparency IG aims to give implementers a clear, standards‑based way to document how AI systems contribute to clinical information—what models were used, what data informed them, how confident they were, and what human oversight was involved. This is not just a technical exercise; it’s a trust exercise. 

This IG just completed an HL7 ballot with over 100 comments. Very good and constructive comments. There is so much work yet to be done to make this IG better and more clear.

Sensitive health topics are improving thru, the SHIFT Task Force and HL7 Sensitivity IG are tackling the nuanced, often fragmented world of privacy‑sensitive data. From reproductive health to behavioral health to social determinants, organizations need consistent, interoperable ways to tag, segment, and protect information that carries heightened risk. 

We are looking for a way to better and more clearly manage valueSets that can inform real-world use of data sensitivity tagging. This was once started by SAMHSA, but that effort has languished for 10+ years. The community need a more sustainable and actionable methodology. 

These are not optional capabilities. They are becoming regulatory expectations, ethical imperatives, and operational necessities.

Why I’m Asking for Support

I’ve always believed in contributing to the standards community. It’s where some of the most important work in healthcare happens. I have benefitted from past employers that allowed me to work on these Privacy and Authenticity topics. But the volume and depth of the current projects have reached a point where continuing entirely as pro bono work is no longer sustainable.

As I work to establish Moehrke Research, I also want to ensure that my contributions to these critical standards efforts remain strong and consistent. Funding would allow me to:

• Dedicate focused time to advancing the AI Transparency IG
• Support the SHIFT Task Force with detailed modeling, examples, and implementation guidance
• Strengthen the HL7 Sensitivity IG with real‑world, policy‑grounded segmentation patterns
• Produce documentation, diagrams, and educational materials that help implementers adopt these standards correctly
• Continue writing openly about these topics so the broader community benefits

In short, support would ensure that this work moves forward with the rigor, clarity, and speed it deserves.

How Organizations Can Help

If your organization depends on trustworthy AI, interoperable privacy controls, or clear guidance on handling sensitive health information, I invite you to consider sponsoring this work. Support can take many forms—direct funding, project‑based engagements, or contributions aligned with specific deliverables.

My goal is simple: to keep doing the work that helps the entire ecosystem function more safely and transparently. With your support, I can continue contributing at the level these efforts require.

If you’re interested in discussing sponsorship or collaboration, please reach out through MoehrkeResearch.com.

Tracking Patient Data Corrections

When data are corrected, especially when the Patient themselves reported that the data was wrong, there needs to be breadcrumbs left behind. Correction is a form of updating of data, but with the special need to indicate that previous data was in error. Some corrections result in the previous data being removed, while others result in the previous data being replaced with corrected data.

Therefore the needs to be a special indication of a correction Provenance, as distinct from a general update Provenance, with the following goals:

1. So that future uses understand the past might have seen different data
2. So that requests for data, especially from outside (e.g. HIE), can see that previous data has been corrected.

The recipient can then find if they have a copy or used the previous data, and take appropriate action.

I have this documented in an IG that has both FHIR R4 and R6 details

- ci-build for FHIR R4 - http://build.fhir.org/ig/JohnMoehrke/correction/branches/main/index.html

- ci-build for FHIR R6 - https://build.fhir.org/ig/JohnMoehrke/correction/branches/R6/index.html

Use-cases

• A patient contacts their provider to report that there is some data that is incorrect. An investigation is done, and the data are found to be in error. The data is corrected, and a Provenance resource is created to indicate the correction.
  • One possibility for this workflow is the HL7 FHIR Patient Requested Correction
• A Quality Improvement process finds that some data is incorrect. An investigation is done, and the data are found to be in error. The data is corrected, and a Provenance resource is created to indicate the correction.
  • One possibility for this detection is an AI system that reviews data and finds potential errors.

Profiling

Recommended use of a Profile on Provenance to indicate corrections:

• activity.coding: will be code FIXDATA from v3-ActReason to indicate that this Provenance is for a data correction.
• reason.coding: can use a set of codes often associated with a correction.
• recorded: will be the time the correction was made.
• target: points at the resource(s) that are corrected.
• agent: indicates who made the correction.
  • the Patient would be indicated here for corrections requested by the patient.
• entity: indicates the records corrected.
  • entity.role=#removal points at the record being replaced or removed (if applicable).
  • entity.role=#revision points at the record being revised (if applicable).
• textual reason can be in why in R6, or in activity.text in R4/R5.
• evidence such as the request for the correction can be in basedOn in R6, or in entity with role=#derivation in R4/R5.

Examples:

• Provenance removal resource documenting the removal of incorrect food allergy observation. This example does not point at a resource that explains the correction, such as a DocumentReference.
• Provenance replacement Provenance resource documenting the replacement of an immunization record that was in error. This example includes a reference to a DocumentReference that explains the correction.
• Provenance AI corrected Provenance resource documenting the detection of an error in FHIR data by an AI system. The original Observation that is error is removed, and a new AllergyIntolerance resource is created to replace it.
• Provenance AI corrected with replacement Provenance resource documenting the detection of an error in FHIR data by an AI system, where the Observation was used to record a food allergy, but the AI system detected that this should have been an AllergyIntolerance resource instead. Thus the Observation is removed, and the AllergyIntolerance is created.
• Provenance patient correction Provenance resource documenting a patient requested correction of their birth date.
• Provenance revision correction Provenance resource documenting the revision of a Condition resource with corrected onset date. In this case the original Condition is revised. Thus the old version history/1 is indicated as revised, and the new version history/2 is indicated as the current version.

changes from R4->R6 Provenance:

• In R6 basedOn would be used to hold the evidence for the correction. Where in R4 would use entity with role=derivation, and in R5 with role=instantiates.
• In R6 patient element exists. Same in R6. R4 didn't have patient, so other methods would be needed to find all Provenance pointing at a patient's data.
• In R6 why exists. This does not exist in R4 or R5. Sometimes the activity.text would be used for this.
• In R6 and R5 authorization is a codeableReference, where in R5 reason is used to hold the PurposeOfUse

Discovering Corrections

To find all corrections for a specific patient, one can search for Provenance resources with Provenance.activity with the FIXDATA code, and where the Provenance points at resources related to the patient.

FHIR R5 and R6

In FHIR R5 and R6 there is a patient element on Provenance, making it easy to find all Provenance resources related to a specific patient. One needs to simply filter on Provenance.activity with the FIXDATA code.

GET [base]/Provenance?patient=[patient-id]&activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA

FHIR R4

In FHIR R4 one needs to search for Provenance resources that point at resources related to the patient. This can be done by searching for Provenance with Provenance.activity with FIXDATA and where the target or entity.what points at resources related to the patient. Since either target or entity.what may point at resources that contain a patient reference, these cannot be combined in a single standard FHIR search query. Both chained searches must be performed and results combined client-side to find all relevant Provenance resources:

GET [base]/Provenance?activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA&target.patient=[patient-id]
GET [base]/Provenance?activity=http://terminology.hl7.org/CodeSystem/v3-ActReason|FIXDATA&entity.what.patient=[patient-id]

Proposed FHIR Document section

I could not find an existing FHIR Document section that covers this topic. For example, in an International Patient Summary (IPS) this could be an additional section. In this way as new Cross-Community requests are made corrections would be communicated. This section contains information about corrections made to the patient's data, including details of the original data, the corrected data, and the reason for the correction. This information is provided to ensure data integrity and transparency in the patient's health record. I propose a new section:

• Section code: http://loinc.org#77472-9 (Information integrity attribute)
• Section title: Corrections to Data
• Section text: Text summary of the corrections made.
• Section entries: Provenance resources documenting corrections made to the patient's data following the correction Profile on Provenance.

Note that loinc code 77472-9 is "Information integrity attribute", which seems appropriate for this section. I am open to other code suggestions.

Conclusion

This is just my view on this use-case. I expect there is experience that might help refine. Please let me know