Of course I use AI tools

This tweet by Scott Manley a few weeks ago keeps coming to my mind... Mostly because it is exactly my thinking. Of course I use AI tools, I have worked too hard to get where I am today to not use them.

Do I trust without question that which comes out of AI, HELL NO! See previous point about having worked too hard to get to where I am today. Which I will note that it is because of my experience that I can detect AI going rogue. It is because of my experience that I can express in the prompt the key important systems-design criteria. It is because of my experience that I define test benchmarks before starting to develop something. 

The deepest thing I have done is use vibe coding to create a security sensitive data labeling service reference implementation -  Security Labeling Service - Reference Implementation

Do I think that AI could kill us all? Well, I have read plenty of science fiction, so I have the background. This worry is also a reason that I use AI, so that I can understand the tool. I do more than just understand, I write about controlling AI, and monitoring AI.

Some blog articles:

• Consent about AI
• AI Assisted Patient Appointment Traceability
• AI Transparency

AI is neither good nor bad; it is a tool. When AI does something bad, the tool just did what the human/organization asked it to do. So, anything bad or good that AI does is not the responsibility of AI, but the human or organization that used the AI tool. 

Modeling Legal Emancipation for Healthcare Access Control with FHIR Consent

 Legal emancipation can change who may make healthcare decisions and who may access a minor's health information. It is not, however, a simple demographic attribute. Its meaning depends on the jurisdiction, the court order or other legal instrument, its effective period, and any conditions or exceptions contained in that instrument. A healthcare system should not infer emancipation from a patient's age, living situation, or an unsupported assertion.

The Emancipation Consent implementation guide explores a FHIR R4 pattern for representing the access-control consequences of a verified legal emancipation. The legal order, decree, or other recognized instrument remains the authoritative record. The FHIR resources make the organization's current interpretation of that evidence visible and enforceable.

The pattern uses Patient for the emancipated minor and DocumentReference, with Binary when appropriate, to retain the legal instrument and its metadata. The Consent references that source document through Consent.sourceReference, identifies the organization applying the policy, and carries only the rules that the organization can actually enforce.

Parents and guardians are represented as RelatedPerson resources. This matters because a relationship is still a positive fact even when the emancipation changes that person's access rights. The Consent.provision.actor references the relevant parent or guardian, while the provision expresses the resulting access rule. In FHIR R4, the single root provision establishes the overall deny or permit direction; nested provisions express exceptions by alternating that direction. This lets an implementation start with a baseline rule and then represent only the legally supported exceptions.

This approach does not claim that every emancipation denies every parent access, nor that it grants a minor unrestricted authority in every context. It creates a place to record the healthcare organization's actionable decision, trace it to the legal evidence, and apply it consistently in an access-control engine. Jurisdiction, legal authority, effective period, verification details, and restrictions should remain available in the source document or in well-defined extensions when they must be exchanged as structured data.

The guide is experimental and intended to encourage discussion. For the profile, examples, and implementation details, see:

• GitHub source repository
• CI build
• Formal publication

Available consulting capacity

Consulting capacity: I have been working three different contracts that are working to profile FHIR using the Implementation Guide (IG) tooling. Only one is active right now and it is at 75% of the past workload. So, I have capacity available to take on new contracts. 

1.  Standards Development / revision
2.  Implementation Guide authoring / revision
3.  Privacy & Security - Consent, Audit, Provenance
4.  Trustable AI - AI-Transparency, Consent for/against AI use, etc
5.  Health Information Exchange - XD*, FHIR/MHD, IPS

More details and contacts on my web site - https://MoehrkeResearch.com.
I do some projects pro bono but would love if someone would care enough about it to contract with me. Sustaining the Work That Sustains Trust: Why I’m Seeking Support for Some of My Standards Efforts