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-.

Age services are a no-win

I have written on Age-Services, those theoretical services that can provide age-protected services a way to learn the age of their user without learning their birthday.  Age Verification is much more important than porn

I hear excited proposals that promote that Apple and Google, as platforms, should be the Age service. Each time, I am yelling into the dark at a very specific problem does not get brought into the picture.

The Age service is a thankless service. It would not be able to be a paid service; it won't be able to include advertising. Which is bad enough. But it is also a huge overhead. The API is not hard to implement. The API could be designed in various ways to protect the individual. What is hard to handle is the backend requirements from government subpoena. 

An Age service must know strongly the identity of the individual, and thus they must know the birthdate. This is rather obvious, but this itself puts the Age Service in the tough spot of protecting from accidental exposure, or malicious attacks. Highly valuable data, means expensive protections. Protections that also must include audit logs of all legitimate uses, as well as requests that are blocked as illegitimate.

Age-Service is far more expensive

This is already an expensive service, that I explain has no revenue stream.

The Age service knows which age-limited services that a given user is using. They will get requests, or need to issue assertions, for a targeted age-limited service. Thus, it is possible for Apple / Google to know what age-limited services a given user is using. When, and from where. Could they not save a log? Possibly, but they could be compelled to save a log. And they need a log to protect themselves from age-protected service claims that they were given an age value that was never released. E.g., I dispensed beer because the age-service said the user was 21, but in reality, no such age assertion was ever issued.

E.g., An age-limited service "cannabis-today" needs to know that the user placing an online order is of legal age, so age-service is engaged to determine this. This use of "cannabis-today" is legal in the state where the company and user live. But one time, the user is out-of-state, in a state where cannabis sales are not legal, and now that state issues subpoena for records. The individual may not have even tried using the "cannabis-today" app, but it was on their phone. --- this story is not just about cannabis --

The knowledge of which age-limited services a given individual is using is valuable to governments that want to control population. Further, they will want the full log to find individuals using age-limited services.

Date Of Birth

Different topic on the same subject... an age-limited service can learn the birthdate of an individual by probing every-day. On the day that the age goes up, that is their birthday. Long time ago SAML had an age service, and they noticed this problem, so they indicated that some fuzzing of the birthdate would be used. However, this presents a problem, does the service indicate age transition early and thus is wrong, or does the service indicate late and make the individual angry about not being recognized as 21 on their birthdate.

Conclusion

Will governments continue to ask for such a system, yes. I am not surprised they will ask for this. I would actually think they are wrong to not ask. But because they ask, does not mean that it should be provided. In my other article I express that many of these age-limited services are services that are needed by disenfranchised and powerless.  The age-limited services are often the only way for these individuals to get access to the services they need. If the age-service is compromised, or if the government is able to compel the age-service to give up data, then these individuals are put at risk.

Considerations for Implementing the SLS RI

In a previous post I introduce a Reference Implementation of a Security Labeling Service. I published this as open-source on the SHIFT SLS RI GitHub Repository. I published the API definition including profile on ValueSet for defining a sensitive tagging ValueSet of codes. With an IG that holds many prototype ValueSets of sensitive topics. I also explain how sensitive topics are a subset of data, distinct from Normal health data.

The SLS Reference Implementation is designed to provide an informative example of how to implement the Security Labeling Service (SLS) for Health Information tagging so that fine grain access controls can be implemented. Data tagging applies a categorization code to a FHIR resource based only on the content of that FHIR resource. The tag does not indicate what kind of access control is applied. The access control rules are separate.

When is tagging needed?

1. Data does not need to be tagged if there is no access control policies (e.g. Consent, Business Rules, or Regulations) that would apply different rules to different categories of data.
2. Data does not need to be tagged if the current state of Consent is blanket permit or deny. That is when the Patient Consent has no specific rules per category then the tagging is not needed.
3. Data need only be tagged sufficient to support the categorization of the access control policies. The SLS RI is configured by loading the SLS Policies as ValueSets
4. When the tagging policies change (e.g. the SLS ValueSets are updated) then any data that was tagged under the old policy needs to be retagged. The SLS RI implements a timestamp on the tags to allow for not retagging if the SLS policies have not changed since last tagging.

The Reference Implementation of the SLS is designed to provide clarity of the concept of tagging. It is not designed to be fast or efficient. In a real-world system, the tagging of the data would be designed into the system utilizing features of that system (e.g., leveraging database indexing).

When to apply the SLS RI?

Executing the SLS against any data is an expensive operation. This is true as the number of entries in the SLS policies increases. The SLS must look at all codes in the data and detect if any of the codes match any of the configured SLS policies. Thus, the more policies (ValueSets) and the more entries in those ValueSets, the more computationally expensive the tagging process becomes. The SLS RI includes a timestamp so that data are not inspected unless the data timestamp is older than the SLS Policies. See ValueSet Profile

There is a concern with legacy databases not having an element to hold the security tags. Thus there needs to be a way to support SLS in those cases.

There are a few ways to apply the SLS RI:

Executed on all data Creation and Update

This is the most comprehensive approach, ensuring that all data are tagged appropriately. However, it may have performance implications due to the need to tag every resource. It also relies on the system being able to persist the tags with the data. This approach also must retag data when the tagging policy (e.g. SLS ValueSets) changes.

This model likely can be implemented efficiently with a systems design of a SLS into the database. Thus, the use of the SLS RI is not likely directly usable if this is the model desired.

Executed on demand when a Patient's data are accessed

When a Patient's data are accessed, a task examines all of that Patient's data and applies the appropriate tags. This approach allows for dynamic tagging based on the current state of the data and the applicable access control policies. However, it may lead to performance issues due to the need to tag data at the time of access, which could introduce latency. It also relies on the system being able to persist the tags with the data. This approach has the benefit of not changing data to add tags unless that Patient is actively being accessed. Thus historic patients that are no longer being accessed would not need to be tagged.

The system should keep some timestamp at the Patient level to know when the Patient was last tagged, so as to keep from running this task unnecessarily often.

Executed on demand with each Search with writeback

When a search is executed, the SLS RI is executed to inspect the Search Bundle and any new tags are written back to the database. This approach allows for dynamic tagging based on the current state of the data and the applicable access control policies at the time of search. However, it may lead to significant performance issues due to the need to tag data at the time of search, which could introduce latency. It also relies on the system being able to persist the tags with the data. This approach has the benefit of not changing data to add tags unless that data is actively being searched for. This inspection of the Search Bundle would only be done if the Access Control decision has residual rules to further remove categories of sensitive data.

Executed on demand with each Search doing only inline tagging

When a search is executed, the SLS RI is executed to inspect the Search Bundle and any new tags are only added to the Search Bundle in memory and not written back to the database. This approach allows for dynamic tagging based on the current state of the data and the applicable access control policies at the time of search without changing the underlying data. However, it may lead to performance issues due to the need to tag data at the time of search, which could introduce latency. This approach has the benefit of not changing data to add tags unless that data is actively being searched for and does not require that the system be able to persist the tags with the data. This inspection of the Search Bundle would only be done if the Access Control decision has residual rules to further remove categories of sensitive data.

🎁Note, this is one of those projects I do 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

Sensitive data as Venn diagram

In Healthcare, Normal data is all data that is linked to an identified Patient and not specifically sensitive. Any data that is sensitive would be Restricted. "Normal" refers to the normal average curve, thus the majority of data. Sensitive data can be categorized into sensitivity topics, and some data may fall into multiple sensitive categories, as illustrated in the Venn diagram below.

Sensitive topics are generally potentially stigmatizing information, for which exposure would present high risk of harm to an individual's reputation and sense of privacy. 

In a data tagging architecture, sensitivity topics are indicated as a "sensitivity" code in the FHIR Resource.meta.security tag of FHIR resources, and can be used for access control decisions in a Privacy Consent driven access control model.

Normal data is often not tagged as Normal, but rather is just the absence of any sensitive tag. This is recognizing that the vast majority of medical data are Normal (algorithmically average). The presence of any sensitive tag would make the data Restricted, indicated as R restricted Confidentiality code.

The data are tagged with the kind of sensitivity purely due to their data content, and not due to any other factors such as the Patient consent status. The labeling does not imply that there is any particular access control policy in place, but rather that the data is sensitive and may require special handling. 

The access control policies would be defined separately and could use the presence of these sensitivity tag to make decisions about who can access the data and under what circumstances. 

For example, when a given patient indicates that broad treatment use of their data is not restricted, but their Sexual Health sensitive data must not be shared beyond their PCP and never with non-Treatment purpose of Use. So, in this case, note that the other sensitive tags beyond Sexual Health have no effect on accessibility. Note that this Consent policy just needs to see the Sexual Health tags, it does not care about Normal vs Restricted. 

Resources:

• An Implementation Guide with various ValueSet(s) that could be used by a Security Labeling Service (SLS) to tag data according to specific sensitivity. - SLS ValueSets
• A Reference Implementation (OpenSource) of a Security Labeling Service (SLS) that I created using Vibe coding with AI - SLS RI GitHub Repository
• An Implementation Guide defining that API, and specifically a Profile on ValueSet to identify sensitivity type and the codes for that type. -- SLS RI Implementation Guide
• Example Patient Data SHIFT Demo Scenarios IG

🎁Note, this is one of those projects I do 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

Consent about AI

There are various use-cases where a Patient might consent or dissent to various uses of AI.

1. A patient might consent to use of AI for clinical decision support
2. A patient might deny use of their data for training of AI.
3. A patient might consent to use of their data in de-identified form for training of AI.

Given the Consent model, the Patient might be indicated in a Consent authorizing either: 

• Generically allowing or denying AI by PurposeOfUse 
• Specifically allowing or denying a specific AI by referencing the Device resource for that AI.

PurposeOfUse

The most clean method is to use the PurposeOfUse as the basis for the provision in the Consent. This allows the Consent to be independent of the specific AI system or model, and thus not require updates as new AI systems or models are developed. The PurposeOfUse can be used to indicate the reason for the AI access, such as MLTRAINING for training of AI, or TREATDS for clinical decision support.

Further we look to PurposeOfUse Vocabulary to indicate what the reason the AI is giving for accessing data. For example, the PurposeOfUse of MLTRAINING is defined for when an AI is looking to train on data. The PurposeOfUse of TREATDS is defined for when an AI is looking to provide clinical decision support, or PMTDS when AI is looking to provide analysis for payment decisions.

The use of PurposeOfUse does require that any accesses the AI does, or an agent feeding the AI, must use the given PurposeOfUse code when accessing data. This is a trust model that the AI or the agent feeding the AI will accurately indicate the PurposeOfUse when accessing data. However, this is a common trust model used in many other aspects of healthcare data access and thus is not unique to AI.

Allow AI for ML Training

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse#MLTRAINING

Consent example: Allow ML Training

Deny AI for ML Training

* provision.type = #deny
* provision.purpose[+] = $purposeOfUse#MLTRAINING 

Consent example: Deny ML Training

Allow AI for Clinical Decision Support

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse
#TREATDS 

Consent example: Allow AI for Clinical Decision Support

Deny AI for Clinical Decision Support

* provision.type = #deny
* provision.purpose[+] = $purposeOfUse#TREATDS 

Consent example: Deny AI for Clinical Decision Support

Specific AI Systems or Models

For this we look to current identification of AI as a FHIR Device resource. This Device would be indicated in a Consent when a specific AI system or model is identified in a Consent.provision.agent.reference with a permit or deny provision.

This model requires that all access by an AI are attributed to the FHIR Device describing the AI. This might not be the case given how the AI is orchestrated. This model also is fragile as a new model or software would be a new Device, and thus would require a new provision in the Consent to indicate consent or dissent for that new AI.

Allow a specific AI for a specific purpose

In this case there is simply a provision indicating that the AI is permitted. There is no purposeOfUse indicated, but that could be an additional restriction. There is no other restrictions on the kinds of actions or the kinds of data, but those could also be additional restrictions.

* provision.type = #permit
* provision.agent.reference = Reference(Device/AIdevice) 

Consent example: Allow specific AI for specific purpose

Limitations on AI Access

In the FHIR Permission there is a concept of a "limit" which is limits placed on a permit provision. Where the limit might be an obligation or refrain, might be a specific additional data tag, or might be explicit removal of data elements. I have made an extension to replicate this "limit" concept so that it can be used on a Consent.provision. A "limit" should never be allowed to expose data where that limit can't be enforced. Specifically meaning that the recipient of the data must be trusted to enforce the obligation or refrain indicated. PermissionRuleLimit Extension

In FHIR R6 one could have a Consent that holds the provisions as a Permission resource, and thus the limits capability is available.

Allow AI for ML Training on De-Identified Data

* provision.type = #permit
* provision.purpose[+] = $purposeOfUse#MLTRAINING
* provision.modifierExtension[limit].extension[control].valueCodeableConcept = $obligation#DEID  

Consent example: Allow ML Training on De-Identified Data

Conclusion

The above examples are showing simply how a Consent.provision iteration can carry permit and deny to indicate consent or dissent for AI. The examples are not exhaustive, and there are many other combinations of provisions that could be used to indicate consent or dissent for AI. The examples are also not indicating any specific data elements that are being allowed or denied, but those could be added as additional restrictions on the provision.

The reader should be able to take a quilted Consent that has various provisions indicating consent or dissent for various clinical use (TPO) and add in provisions indicating consent or dissent for various AI use-cases, and thus have a single Consent that indicates the patient's preferences for both traditional clinical use and AI use.

The above examples are available in a draft IG on Consent About AI. That IG might further refine and improve beyond this blog article.

🎁Note, this is one of those projects I do 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

Security Labeling Service - Reference Implementation

I have spent far too much time with Co-Pilot AI, but I am so happy with the output. I have vibe coded two applications. I wrote in a readme what I wanted done, and co-pilot produced a working application on the first try. I then spent two days improving (adding features and robustness) them. I never needed to touch code, I just typed what I wanted changed, improved, or fixed.

I have insisted that the apps clearly indicate their Provenance: 

This application was developed by GitHub Copilot (Claude Sonnet 4.5) ..., at the direction of John Moehrke of Moehrke Research LLC. 

SAMHSA ValueSet viewer

The fist vibe coding project I had was to create a github.io app that allows me to see the contents of a given set of ValueSets from SAMHSA. The reason I needed this is because some of these are too big for the IG Publisher to render the expansion. I had asked to have a setting that would set the IG Publisher 1000 entry max to 2000. But this request was rejected. So, this was my inspiration.

All I did was ask co-pilot to make me an application that can use a FHIR defined $expand operation against the tx.fhir.org server, for a list of ValueSets by url; and display the results.  

This was a total of 15 minutes of my time. I then proudly told my family, and my boys proceeded to break it. Turns out a feature I asked was the "Check All Sizes", and that was introduced a bug if run first. So, I told co-pilot about this effect, and it fixed it. Add 5 more minutes.

Try it out at SAMHSA ValueSet Viewer. Don't beat on it too much as it does use tx.fhir.org.

Security Labeling Service - Reference Implementation

This one is far bigger, and I have been thinking of asking AI to make this one for me. I created a github repository, and wrote a README.md with just a few words about what I wanted done. Mostly what you see at the beginning of the current README.md; although this has been touched up as I asked for more features. 

Again, the result of the first try worked. I have since improved it in ways that I failed to explain in my original README.md ask. I failed to explain that I wanted a docker deployable server, that the API must be FHIR $operation compliant, that it needs to support ValueSet with multiple topic values, etc.

I was impressed that it started with a sample ValueSet bundle, and sample data Bundle. Very simplistic, but reasonable. These have since been updated to test some of the features added.

What took the most time is that I wanted to be sure that this SLS worked. For this I needed to have complex ValueSets, and complex Data. In both cases I have been working in SHIFT-Task-Force on these very things. I had an IG that had both together.  First I chose to break the data use-cases out from the SLS and ValueSets. The main reason was that I know there is going to be significant improvement in the data use-cases; and the ValueSets cause the build to be very slow. In the ValueSets, I have many to choose from, but I chose to use the ValueSets that are derived from the existing LEAP SLS Reference Implementation. This is an early open-source and suffers from having the codes hard-coded into the source code. 

So I have the data from the use-case, and it is "in theory" already properly tagged. Turns out, that tagging had some errors. I had ValueSets, but they needed to be rearranged and have topic indications. It is this topic indication that is key. These ValueSets are specific to a kind of sensitive data. That is to say the definition of what is composed in the ValueSet is a bunch of clinical codes or hierarchy of codes. The ValueSet then needs to be identified with the Sensitive code that it represents. That is to say that ValueSet (A) has a topic of "BH" (in the hl7 vocabulary this is behavioral health), and composed in the valueSet is behavioral health indicating codes from loinc, snomed, icd, etc.

Testing these ValueSets and data Bundles did find a few more bugs, and a few more features to add. I do have even bigger ValueSets and data to try, derived from S

I'm not going to go deeper here, as this is available as Open-Source, and there is an Implementation Guide with the defined FHIR Operations.

Conclusion

Next up is to see if my kids can break this.  Another reason to not further explain it here, as any fixes I make will show up on the github.

I will note that my household is odd. My kids hate AI, with a passion. I seem to be doing okay with it. One would expect that the old-man would be the one with an aversion to AI. I am very suspicious, I have seen it really mess up, and I have seen the movies enough to worry about what it might do. But I choose to work with it in order to make it better at helping humans.

🎁Note, this is one of those projects I do 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

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.