AI Helps Write the Translation. It Does Not Translate the Data.

One of my projects is to support the FAST NDH directory IG development in HL7. As part of this, I was asked to create computable mappings from HL7 FHIR Plan-Net Implementation Guide to the HL7 FHIR National Directory of Healthcare Providers and Services (NDH) Implementation Guide. Both describe healthcare directory information. They look similar, but their representations differ: extensions, vocabulary, and profiles are not interchangeable. Similar-looking data is not necessarily conformant data.

FHIR Mapping Language (FML) expresses explicit rules for transforming source data into target data, including copying fields, translating codes, and mapping extensions.

I have been using Visual Studio Code and GitHub Copilot to author and update these maps.

AI is helping write the rules. AI is not translating the data.

The translation is performed by explicit FML rules, executed using the FHIR Validator's transformation capability. There is no language model deciding what a field means each time a resource is processed.

VS Code + Copilot
       |
       v
   FML rules
       |
Source samples --> FHIR Validator transform --> NDH output
                                                   |
                                                   v
                                         Validate NDH profiles

Faster Authoring, Not Automatic Trust

Copilot made authoring and updating the FML much quicker. It helped work through repetitive mapping rules and revise them as testing exposed problems.

That is useful. It is not evidence that the resulting maps are correct.

The rules remain inspectable, editable, and testable without AI. The translation behavior belongs in those rules, not in a prompt.

Samples Are Part of the Work

I use source-conformant examples to exercise the maps continually. The samples include both:

• Data reflecting how implementations currently use Plan-Net.
• Comprehensive examples exercising more of what the source format supports.

These serve different purposes. Implementation data shows what is happening. Comprehensive examples exercise fields and extensions that everyday data might never populate.

A map tested only against sparse data can look complete while doing very little.

Multiple sample sources help expose assumptions that a single dataset would hide. Downloaded implementation data also needs scrutiny; being returned by a FHIR server does not establish conformance.

Transform, Validate, Inspect, Repeat

Scripts repeat the transformations and validate the resulting resources against the target NDH profiles. They retain outputs, logs, and per-input results so failures can be investigated.

I also use AI to spot-check source and transformed resources for lost information. Automated checks supplement that inspection, including checks that extensions intended to be preserved actually survive.

These checks answer different questions:

• Did the transformation execute?
• Does the output conform to NDH?
• Was the source information preserved or intentionally translated?

Passing profile validation does not prove that nothing was lost. AI spot inspection does not prove it either. Both are useful, but neither replaces explicit preservation checks and broader test coverage.

The Point

This is a practical use of AI: accelerate development of deterministic, reviewable transformations, then test them repeatedly.

Use AI to help write the translation. Do not confuse that with trusting AI to perform—or certify—the translation.

For a deeper discussion of this approach, see Firely's Language Models Should Write Your FHIR Mappings.

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

Why Patients Don’t Get Detailed Audit Logs — And Why We Still Need to Record Them

Healthcare generates an enormous amount of digital exhaust. Every lookup, every exchange, every routing hop, every system‑to‑system handshake leaves behind an audit trail. Yet patients rarely see any of it — and, importantly, U.S. regulations do not require that they do.

This creates a paradox: Audit logs are essential for trust, accountability, and safety, but giving them directly to patients would overwhelm more than empower.

In this article, I’ll unpack the regulatory reality, explain why audit logging still matters, and show how standards like FHIR AuditEvent and IHE Basic Audit Log Patterns (BALP) provide the foundation for meaningful transparency — including future patient‑facing safety tools.

Patients Don’t Get Full Access Logs — And That’s By Design

Let’s start with the misconception: There is no U.S. regulation requiring healthcare organizations to give patients a detailed log of every access, use, or disclosure of their data. (Note that GDPR in the EU is far more actionable, so those in that region can skip to the next section)

HIPAA’s Accounting of Disclosures sounds like it might do this, but it doesn’t. It excludes:

• Treatment

• Payment

• Healthcare operations

• Most internal access

• Most external exchange

• Most analytics

• Most quality improvement

• Most care management

• Most research

• Anything with patient authorization

In other words, HIPAA’s accounting requirement covers only a narrow slice of activity — mostly only the activity that the patient had to be directly involved in requesting or authorizing (explicit consent). Thus, this report is not all that useful.

TEFCA Changes the Landscape — But Only Slightly

TEFCA introduces something new: QHINs must support patient access to a report of where their data was exchanged through TEFCA.

This is meaningful, but limited:

• It applies only to TEFCA-governed exchange

• It reports exchange, not use

• It does not include internal access

• It does not include non‑TEFCA exchange

• It does not include analytics or operational uses

TEFCA is a step toward transparency, but not a full “data use report.”

So Why Record Detailed Audit Logs If Patients Don’t See Them?

Because audit logs serve three critical purposes:

1. Regulatory Compliance (Even If Not Patient-Facing)

HIPAA, HITECH, TEFCA, CMS, and state laws all require organizations to maintain audit trails. Even if patients don’t receive them, regulators may demand them.

2. Security and Abuse Detection

Audit logs are the backbone of:

• Insider threat detection

• Account compromise detection

• Access pattern analysis

• Breach investigation

• Forensics

Without detailed logs, organizations cannot detect misuse or prove compliance.

3. Future Patient-Facing Transparency Tools

Even though patients don’t get raw logs, they will benefit from tools built on top of them.

This is where standards matter.

FHIR AuditEvent + IHE BALP: The Foundation for Trustworthy Logging

FHIR AuditEvent provides a structured, interoperable way to record:

• Who accessed data

• What they accessed

• When

• From where

• Under what purpose

• Using what authentication

• Through what system

• With what outcome

IHE Basic Audit Log Patterns (BALP) adds:

• Consistent patterns for common events

• Reusable structures

• Cross‑system interoperability

• Guidance for routing audit logs

• Patterns for retention and disclosure

Together, they create a uniform audit fabric across systems — something TEFCA participants, QHINs, and EHR vendors can all rely on.

Why Patients Shouldn’t Receive Raw AuditEvent Logs

Even though AuditEvent is structured, it is still machine‑level detail.

A typical AuditEvent entry might include:

• IP addresses

• OAuth token identifiers

• System‑to‑system routing metadata

• Internal user IDs

• Service account activity

• Background processes

• Automated system checks

• Batch operations

• Retry attempts

• Internal queue processing

Giving this directly to patients would create:

• Information overload

• Misinterpretation (“Why did 17 different systems access my record at 2 AM?”)

• False alarms

• Support burden

• Privacy risks (exposing internal system architecture and monkey business)

Patients need meaning, not machine logs.

The Future: Patient Safety Apps That Watch Audit Logs for Them

The real opportunity is not patient access to raw logs — it’s patient access to insights derived from logs.

Imagine an app that:

• Monitors AuditEvent streams

• Learns normal access patterns

• Detects anomalies

• Flags unusual access

• Alerts the patient only when something looks wrong

Examples:

• A provider in another state accessed your record

• A system account accessed your data outside normal hours

• A TEFCA participant requested your data for an unusual purpose

• A pattern suggests credential compromise

• A sudden spike in access suggests a breach

This is machine learning + audit logs + patient empowerment.

It’s the same principle as fraud detection in banking: You don’t get a list of every transaction routing hop — you get an alert when something looks off.

Conclusion: Logs Matter — Even When Patients Don’t See Them

Patients don’t get detailed access logs today, and regulations don’t require it. But detailed audit logging is still essential — not for patient consumption, but for:

• Compliance

• Security

• Forensics

• TEFCA reporting

• Future patient‑facing safety tools

FHIR AuditEvent and IHE BALP give us the technical foundation. TEFCA gives us the regulatory nudge. The next step is building patient‑friendly applications that turn audit logs into actionable safety signals.

That’s how we move from “audit logging as compliance” to audit logging as patient protection.

Profiling AuditEvent seems to be an emerging need

Watching the report outs for the CMS FHIR Connectathon. Many are mentioning that they see a need to profile AuditEvent for their use-case needs to support data access traceability, privacy tracking, and provenance. I very much agree with this. 

IHE has the starter kit with the Basic Audit Log Patterns (BALP)  Implementation Guide defines the basics and has some profiles for common REST interactions.

I often need to remind people that defining AuditEvent profiles can be supported purely as a Query interface. In this case the system keeps their audit log in their native format, but knows how to convert that into the FHIR Standard AuditEvent when queried.

I would be glad to provide pointed and short-term consulting -- see Moehrke Research LLC 

proud owner of an OID root

Now that HL7 is bringing back the OID, as CDA can only handle OIDs and not URL system values. I went and registered with iana for my own OID. It is not important to do this, but it is free. Now all of the test IGs that I have in my personal github can have their own OID root so that I don't need to constantly indicate in the ignorewarnings.txt that it is okay that my test IGs don't have OID assignments.

My assigned OID root: 1.3.6.1.4.1.66281

I have been using the official example OID root: 2.999; which is the equivalent of the DNS example.com, or example.org. I have used this 2.999 OID root with the IG publisher, which I felt was an appropriate defiance. Unfortunately, it just changes the warning.

I have a page that I refer to often on creating and using Unique IDs - UUID - OID

On that article I did add comments that explained the 2.999 OID root. -- https://oid-base.com/get/2.999

I have also noted that USA SSN has reserved those SSN numbers starting with 666. I have not seen an official statement to this, but plenty of confirmations. The concept is that they know they can't issue a 666. number to someone as that someone would see it as the USA government labeling them with the mark of the devil. So when I make test patients, I give them SSN starting with 666-.