HL7 V2 to FHIR

You may have seen my guest post on Healthcare IT Today about Why Public Health Data needs to Modernize a few months back.  I've been working to support this for years, and in October 2025, HL7 achieved a pretty significant goal supporting that.  The HL7 Version 2 to FHIR Standard for Trial Use was finally published.

I have been working on the HL7 Version 2 to FHIR project since the initial inception in late 2018, almost at the same time as I started at Audacious Inquiry.  My first project at Audacious was to create a V2 to FHIR Converter, which we did build and provide to some of our customers.  Audacious contributed the mappings our team developed (mostly through efforts of our product owner and me, with some help from our HL7 V2 interface developers) to the project in early 2019, and they became the initial spreadsheets that were used to create the HL7 V2 to FHIR guide.

I now have the somewhat dubious attribute as having be an editor working on one of the longest running projects from inception to STU publication in HL7 history (7 years).  Yes, I am certain some have run longer, but none that I can think of off the top of my head.  Part of my editorial role in the early days was to have evolved the effort to represent the content in spreadsheets, and then to translate (in code), those nearly 400 spreadsheets into over 250 FHIR ConceptMap resources.  More recently, it has been maintenance of the V2 to FHIR IG generator code base, and detailed technical review of the content produced in the guide to verify that it can be accessed in computable form, not just via spreadsheets but through the FHIR Resources, and ensuring that all content is consistently handled and can be used to automatically generate a V2 to FHIR converter.

I'm thrilled to see this finally published, and our team has been working on turning the output of this guide into a Data Modernization offering for public health that will enable them to turn legacy data into FHIR resources that can be accessed through modern APIs.  We are working on a completely new software base to support V2 and CDA to FHIR conversions we'll be talking more about at HIMSS 26.

It's still Wednesday at the HL7WGM (barely)

It's been too long since I've written an HL7 Plenary Wednesday post, but if you understand the history of this blog, you know what is coming.  For rather understandable reasons, I have shifted a great deal of my focus towards implementations and standards supporting Public Health, rather than the EHR space.  Some of that has to do with what my employer Audacious Inquiry does, but other parts of that stem from seeing an unmet need that can impact people around my country, and even more so, the public health people working very hard, and on very limited budgets to keep us all healthy.  That unmet need became even more apparent as we went through COVID-19 and are still in many ways recovering from it.

Significant effort is underway even now to connect public health to the health information eco-system that we in HL7, IHE and other organizations have been creating for patients.  One of those efforts is to enable public health agencies to connect to that eco-system through TEFCA and national networks to make it easier, cheaper and faster to do the jobs that need to be done, and to improve the infrastructure that is long overdue for a major upgrade.

Over the last couple of years, I met a young leader whose team is developing tools to enable public health agencies connect to the Health Information Superhighway we have been trying to create for the past two decades. Over the past year, I worked closely with him and his team at two different FHIR Connectathon events to better enable agencies to build on-ramps to that expressway.  Through his work, I've been able to make some on-ramps of my own that should enable public health agencies better access to their own data using a more modern infrastructure and achieve a five-year goal I set for myself back in early 2021.

This next recipient is someone I've not had a chance to watch over a long period of time, nor see him grow (though I know he has even in the short time I've known him).  He does what all good leaders do, which is to enable others to succeed, and by others, in this case, I mean me.  We have infrequent contact, we don't really work on the same project, but where our roles intercept, he's made it possible for me achieve a significant goal. Without further ado, here's the next Ad Hoc Harley.

For Daniel Paseltiner, of Skylight 

For leadership that enabled me an opportunity to nail a 5-year goal

P.S. I know this post was more about me than Dan, and for that, I'm sorry.  I do wish Dan and I had more opportunities to work more closely together on a project.  To see some of the work of Dan and his team, check out the DIBBS Query Connector project on GitHub.

   

My Favorite Tools for Building FHIR Implementation Guides for IHE and HL7

I've been doing a lot of implementation guide development lately, and have some favorite tools that I'm starting to work with.  Here's a look at what I've been using.

Source Code

The first of these is a source code repository.  I've been using GIT for source control, and github.com as a free repository for IG development.  You can look at two of the guides I've developed at github.com/IHE/ACDC and github.com/HL7/fhir-project-mhealth to see two of the projects I've built using this toolset.

Editing Content

I like writing content in something simple.  A long time ago I prototyped a process for IHE whereby we created IHE Profile content on the IHE Wiki.  Wikitext in MediaWiki is nearly the same as Markdown.  The value of using something like this is that it allows contributors to focus more on content and less on formatting or making things pretty.  Pretty is good, but that should be the purview of a single person with appropriate design skills rather than a dozen volunteer editors.

Text Content

So, these days, I'm using a the fairly simple Markdown editor provided in Eclipse (more on that later).  There are plenty of Markdown editors you can use, many which work in Eclipse.  I also use FluentMark from time to time.  My favorite XML Editor also supports JSon and Markdown content.

One of the challenges that contributors often have with Markdown is that it's really not very user friendly for editing and creating content pages.  Confluence or other Wiki style pages are a good place to enable not technical users to create content.  Unfortunately, they don't integrate well with source code control systems.  I'm going to look into some solutions whereby we can get some good content editing that integrates into git-based solutions.

Image Content

My biggest used for image content is with structured images, for example UML Use Case, Sequence and Class diagrams.  My goto editor for this material is PlantUML.  PlantUml has an Eclipse plugin that allows you to view UML diagrams within Eclipse while you edit the diagram in a text editor.  You can also run PlantUml from the command line to automate the process of image conversion.  This makes it really useful in automated builds.

XML and JSon Content

I'm really happy with Oxygen XML Editor for editing structured content like XML and JSON documents.  Happily, it also supports Markdown so I can use it for that too.  It has some features that are helpful for finding invalid Unicode characters, something that shows up frequently when you copy and paste text from Word into your markdown documents.

Converting from Microsoft Word or Other Formats

For those that have a lot of content already in Microsoft Word or PDF or other formats, PanDoc is an excellent open source tool for converting content between these formats and Markdown.  PanDoc supports a number of flavors of Markdown, including CommonMark which is the format used by the HL7 Implementation Guide Builder.

FHIR Profiles and Instances

There are a number of different tools that support building FHIR Profiles and instances.  The original FHIR specification build tools allow you to specify profile content in Microsoft Excel, but that's pretty complex tool chain for most user's.  Today, I'm using SUSHI which compiles FHIR Shorthand into Profiles and example instances.  This is an open source tool developed by an award winning team of people over at Mitre.  While still very much a work in progress, it's already saved me a tremendous amount of time, and the Mitre team has been very responsive.

Build Environment

Integrated Development Environment

These days I use Eclipse as my integrated development environment.  I'd love to figure out a way to make of the editing capabilities available using something like Confluence and provide some automated conversions so that when you create or update a content page, you have an easy way to edit the sub-components it requires (e.g., other content pages in links, or images or example content).

Build Automation

Right now my build environment is very much command line and batch file driven.  What I'd like to do is turn it into a Maven project with dependencies on the various editing and other tools described above.  That way I could build a template project which would automate the build of the IG Content.

IG Builder

I use HL7's IG Builder tool to generate an implementation guide.  Between that and github, it automatically deploys my draft IG to http://build.fhir.org/ whenever I commit something.  However, I like to do a local build to confirm that I'm going to get what I want, and it takes less time to test things out that way.

To perform a local build, I also need to install Jekyll, and to use that I need Ruby.

Putting it All Together

To put this all together, what I'd love to see is an installer that would:

1. Install or use an existing Java VM
2. Install or use an existing set of Git Tools
3. Install or use an existing set of Maven Tools
4. Install or use an existing Eclipse installation
5. Install PlantUML with Eclipse
6. Install or use an Node.js installation (required for Sushi)
7. Install or update the current version of Sushi
8. Install or use an existing Ruby installation.
9. Install or use the existing Ruby Dev Tools.
10. Install or use an existing Jekyll installation.
11. Provide an example projects with pre-constructed outlines following best practices for
1. HL7 FHIR Implementation Guides
2. IHE FHIR Implementation Guides / Profiles
3. IHE non-FHIR Profiles (to demonstrate that IG Builder can be used for these).
12. Provide example plantuml files for use cases, sequence diagrams, and actor / transaction diagrams that are often used in IHE profiles and could be used in other Implementation Guides.
13. Provide documentation for the whole package on how to use the various parts of it.

Upgrading HAPI on FHIR (part 2)

I'm still in the process of upgrading FHIR Microservices that have been developed using HAPI on FHIR 3.6 to HAPI on FHIR 4.0.  Earlier this week I shared my initial experiences, here's a few more.

Most of the subsequent challenges I've had are related to upgrading from Spring 1.5.6 to 2.1.1 and consequent changes updating my tracing libraries.

But I've found two tricky issues related to other components, one related to HL7 R4 classes and the Validator, and another related to uses of Embedded MongoDB for some of my testing.

Too many QNames

The first issue relates to uses of the XPP3 libraries that Grahame likes to use for efficient XML parsing.  The challenge here is that XPP3 is ancient and not being actively maintained.  Soooooo...
it exists before Oracle added javax.xml.namespace.QName to the Java Runtime library, and as a result, XPP3 rolled their own (actually, they copied it from an Apache Axis implementation) to support parsing.

The key problem for this is that the javax.xml.namespace is already defined in the JRE in a modular fashion, and so cannot be defined on the classpath when using a JRE after Java 8.  I'm using OpenJDK 11, so I'm affected.
I had a workaround which meant that I never really noticed this, because prior to Eclipse release 2019-06, you could have your JRE on your classpath, and it wouldn't cause a problem, but if you placed it in your imports modularly, then it would.

Having recently upgraded my Eclipse release to 2019-06, which no longer allows you switch the JRE libraries from the modules to classpath entries, I cannot work around the issue in local Eclipse builds.

The simple solution seems to be to strip the javax.xml.namespace.QName class from my downloaded XPP3 (1.1.4c) jar file, and use that instead of the usual one.  I'll probably rename it, put it into my local Maven repo with a patch, and exclude the dependency from my current build in favor of my patched version.  Hopefully, we can get it corrected in a slightly less hacky way (by getting whoever is currently interested in maintaining XPP to make the fix).

Updated: 10/11
James Agnew suggests using xpp3_min, which would address this problem.

Using Embedded MongoDB for Testing

The second problem I'm still digging into.  Since I've got some interest in testing locally and using MongoDB APIs for persistence, I want to be able to do testing with Embedded Mongo DB with my Spring Services.  Unfortunately, I'm still struggling with the upgrade for spring-data-mongodb and flapdoodle.  There's something somewhere that's changed that means that MongoDB no longer knows how to convert the data I'm working with.  I'll figure this one out eventually, but based on my research (StackOverflow and elsewhere), I'm not the first person to struggle with this challenge.

Updated 10/12
Finally figured this one out.  Some automatic configuration for MongoTemplate changed in Spring-Boot-Data after 1.5.6, and to simplify, I just added the collection names to my various calls to create/update/read/query/delete data, and the problem eventually disappeared.

Strange Dreams and Context Controls in HL7 CDA

One of the challenges of a job that requires a lot of thinking is that it's really hard to escape it sometimes.  Last night, just before I head off for a short trip to the cape, I was dreaming about context controls in CDA documents.


Did I just lose you?  Yeah, I was wondering about that myself.

The CDA Document enumerates a number of participations, and for many of these participations, fixes the contextControlCode value to "OP", a code that means Overriding and Propagating, as in the example below from the CDA R-MIM.

What the heck does this mean?

In RIM Speak, context controls describe how the participation applies to not just the act the author participation is attached to (the CDA Document), but also the acts descending downwards (in the direction of the arrows) from the act in which the participation is attached.

So, if you have a CDA Document, it can have sections (a descendant act), which can have entries (a descendant act), and those entries can reference other things (like reference ranges) and so on.  And if, at the top of the document (/ClinicalDocument/author), you say that the author is Alex, then that propagates through the act and all related acts (in the direction of the act relationship arrows) until that same type of participation is again encountered.  At that time, the new participant (Bobbie) overrides the existing one, and propagates downward as the author of all attached and decedent acts.

This behavior is crucial to the way that participations work in CDA, and fortunately, all essential participations work that way.  The way it is crucial is because you can, using XSLT  (yeah, I know, who the hell else do you that dreams in XSLT...) create an XPath expression that identifies the author (or recorder, or performer) of a particular event.

Say you are looking at an allergy in a CCDA Document.  Who's the author of this thing?  Basically, you look at the act (in this case the observation using the allergy template).  If that has an author, you stop there.  Otherwise you look to the act above it to see if it has an author, and so on, all the way to the top of the document (which is /ClinicalDocument), and which, is guaranteed (according to the CDA R-MIM and Schema) to contain at least one author.  Once you find an act that has at least ONE author, you then accumulate all authors as the author of the act.  Assuming your current context is an act that you want to find the author of, here's the XPath expression that identifies all authors of the current act.

ancestor-or-self::cda:*[cda:author][1]/cda:author

What does this say?

Component	Meaning
ancestor‑or‑self::	Starting with the current node and ascending to all of its ancestors in order through the root of the document.
cda:*	Find any element ... note, that while this expression will allow traversal through both act and act-relationship links, the next element will only ever be true on acts (because only acts can have author children).
[cda:author]	That contains an cda:author element
[1]	Stop after you find the first one
/cda:author	Collect ALL of the authors.

So, this will find the first act that specified an author, and collect all of the authors.  If you are trying to translate from CDA to FHIR, this is an essential tool you can use to find author, informant, subject, or other participant.

You cannot assume that just because Alex authored the document that he / she authored all acts within it.  You have to look.

One important adjustment to this.  The subject of every act is assumed to be the patient, unless subject is otherwise specified, but the patient participation is actually identified through the record target participation in CDA.  This is inference from semantics, rather than true semantics, but that's OK.  The way to adjust for that is to use the following to get to the "subject" of the act:

ancestor-or-self::cda:*[cda:subject|cda:recordTarget][1]/(cda:subject|cda:recordTarget)

You may have to fiddle a bit around the use of parentheses depending on whether you are working in XSLT 1.0 or 2.0 (or even 3.0), but you should be able to make it work.

     Keith

Telling Time the HL7 Way

If you've never been to an HL7 Working group meeting, you'll run into some shorthand that long-time HL7'ers know that you'll have to catch up on.  The first is how we split up the day.

Officially, the day has 4 quarters, with breakfast, lunch and two breaks:

• Breakfast starts 8-ish, and goes until 9:00.
• Q1 goes from 9-10:30am
• Morning Break is 10:30-11am.
• Q2 is from 11am - 12:30pm
• Lunch goes from 12:30-1:45pm.  There's plenty of time to each, call home, and take a short meeting.
• Q3 is 1:45-3pm and is a "short" quarter by 15 minutes.
• Cookie break is 3-3:30pm.
• Q4 goes is 3:30-5pm.

A "Q0" meeting (not part of the official nomenclature, but still well-understood) is before breakfast, usually 7-ish, but could also be "overlapping" with breakfast.

"Q5" and "Q6" are generally "after 5" till about 6:30-ish, and after "Q5" till whenever...  This is often where some good work happens (some would even say "the real work").

If you are doing HL7 meeting stuff from Q0 to Q6, you still have 12 hours for your day job and sleep.  Your mileage may vary.

Monday after 5pm is the cochair's dinner.  If you want to hang with a cochair, they are likely busy from 5-7:30 or so Monday night.

Wednesday starting around 5:30 is the HL7 Reception.  This goes until about 7:30.

The first half of Monday in September is the Plenary session.

Monday and Tuesday at the WGM in January are the two Payer Summit days.

Connectathons are Saturday and Sunday before the Working group meeting.  Quarters?  Yeah, kinda.  We have them, food shows up at the right times.  But it's a Connectathon, software is ready when it's ready.  Some have been known to work until Q8 or 9, and maybe even start at Q -1.

I wanna say board meetings happen somewhere in Q3 and 4 on Tuesdays, but it's really up to the chair.

Technical Steering Committee (a governance committee) meets Saturday and Sunday.
International Council is Sunday and Thursday Afternoon.
Education Facilitators Lunch is Monday most meetings.

   Keith

Terminology Drift in Standards Development Organizations

I used to work for a company that published dictionaries, and one of my colleagues was a dictionary editor.  As he related to me, the definition of a term doesn't come from a dictionary, but rather from use.  A dictionary editor's job is to keep faithful track of that use and report it effectively.  By documenting the use, one can hope to ensure consistent future use, but languages evolve, and the English language evolves more than many.  I've talked about this many times on this blog.

It also happens to be the common language of most standards development organizations in Health IT (of course, I, as an English speaker, would say that, but the research also reflects that fact).

The evolution of special terms and phrases in standards is a particular challenge not only to standards developers, but especially to standards implementers.  As I look through IHE profiles (with a deep understanding of IHE History), I think on phrases such as "Health Information Exchange", "XDS Affinity Domain", and "Community", which in IHE parlance, all mean essentially the same thing at the conceptual level that most implementers operate at.

This is an artifact of Rishel's law: "When you change the consensus community, you change the consensus" (I first heard it quoted here, and haven't been able to find any earlier source, so I named it after Wes).

As time changes, our understanding of things change, and that change affects the consensus, even if the people in the consensus group aren't changed, their understanding is, and so the definition has changed.

We started with "Health Information Exchange", which is a general term we all understood (oh so long ago).  But then, we had this concept of a thing that was the exchange that had to be configured, and that configuration needed to be associated with XDS.  Branding might have been some part of the consideration, but I don't think it was the primary concern, I think the need to include XDS in the name of the configuration simply came out of the fact that XDS was what we were working on.  So we came up with the noun phrase "XDS Affinity Domain Configuration", which as a noun phrase parses into a "thing's" configuration, and which led to the creation of the noun phrase "XDS Affinity Domain" (or perhaps we went the other way and started with that phrase and tacked configuration onto it).  I can't recall. I'll claim it was Charles' fault, and I'm probably not misremembering that part.  Charles does branding automatically without necessarily thinking about it.  I just manage to do it accidentally.

In any case, we have this term XDS Affinity Domain Configuration, which generally means the configuration associated with an XDS Affinity Domain, which generally means some part of the governance associated with a Health Information Exchange using XDS as a backbone.

And then we created XCA later, and had to explain things in terms of communities, because XCA was named Cross Community Access rather than Cross Domain Access.  And so now Affinity Domain became equivilated (yeah, that's a word) with Community.

And now, in the US, we have a formal definition for health information network as the noun to use in favor of how we were using health information exchange more than a decade and a half ago (yes, it was really that long).

So, how's a guy to explain all this means the same thing (generally) to someone who is new to all this stuff, and hasn't lived through the history, and without delving into the specialized details of where it came from and why?  I'm going to have to figure this out.  This particular problem is specific to IHE but I could point to other examples in HL7, ISO, ASTM and OpenEHR.

The solution it would seem, would be to hire a dictionary editor.  Not having a grounding in our terminology would be a plus, but the problem there is that we'd a need a new one periodically as they learned too much and became less useful.

Find your Informatics mentor at IHE or HL7

I was interviewed yesterday by a college student as part of one of her student projects.  One of the questions I was asked was: What would be your one piece of advice for a graduating student entering your field?

I told her that it would depend (isn't that always the answer?), and that my answer for her would be different than my general answer (because she's already doing what I would have advised others).

My general answer is to find an group external to school or work related to her profession to volunteer in, either  a profession association or a body like IHE or HL7.  I explained that these organizations already attract the best talent from industry (because company's usually send their top tier people to these organizations).  So, by spending time with them, she'll get insight from the best people in the industry.

Organizations like this also have another characteristic, which is that they are already geared up to adopt and mentor new members.  I think this mostly might be a result of the fact that they already have more work than they can reasonably accomplish, and having a new victim member to help them is something that they are naturally supportive of, and as a result, also naturally supportive of the new member.  It's an environment that's just set up to provide mentoring.

There are days when I'm actually quite jealous of people who get to do this earlier in their career than I did.  Participating in IHE and HL7 has given me, and many others quite a boost in our careers, and the earlier that acceleration kicks in, the longer it has to effect your career velocity.  In her case, I'm especially jealous, as she's been working in this space since middle school!

In any case, if you are a "newly" minted informaticist, health IT software engineer, or just a late starter like me, and want to give your career a boost, you can't go wrong by participating in organizations like IHE, HL7, AMIA or other professional society or organization.

   Keith

The January HL7 Working Group Meeting

HL7 Working Group meetings are a phenomenal way of keeping up with what HL7 is doing. The biggest challenge I have is that I cannot be everywhere at once.  January is also the HL7 Payer Summit, and so there is a lot of activity going on.

The working group meeting starts on Saturday with two activities: The FHIR Connectathon, and the International Council meetings.  I didn't go to either this year, but heard we had about 240 people at the 20th FHIR Connectathon.  I expect to be at the next Connectathon.  For a variety of reasons, a lot of payers were in attendance at the FHIR Connectathon trying out some of the new Da Vinci profiles (e.g., CRD).

While I had some minor challenges with my flight out on Sunday (for some reason my expense application notified me of flight cancellation, but United completely failed to let me know until I arrived at the airport), I did arrive just in time for the working group meeting "proper", the Monday to Thursday (and sometimes Friday) meetings that make up the bulk of HL7 activities.

Structured Documents reviews their plan for the week first thing Monday morning, and I make mine.  I still consider SDWG to be my "home committee", but my interests are too divergent to spend time with any single group.  My plan for the week was to spend some time with SDWG, CQI and CDS, Patient Care in a large joint meeting with CQI and CDS and others, Attachments (another "old home"), and FHIR-I (joint with SDWG). Structured Documents is one of the work groups piloting the use of Confluence to capture the WGM activities.  You can see the output from SD here, including the results of the Wednesday morning, and Wednesday afternoon sessions that I also attended. 

Provenance

The Monday joint meeting with Patient Care discussed a new Provenance project, which several workgroups have interest in.  PC was going to sign on as a "Interested Party", a commitment with no actual governance associated with it, and there was some ongoing discussion during the week between the Security Workgroup, the Community Based Care and Privacy workgroup (formerly Community Based Collaborative Care, renamed to effect what has been the reality for this workgroup over the last half-decade) about who might become primary sponsor.  I had suggested the EHR workgroup (not even in the room at the time, but the one workgroup who had published functional requirements on Provenance, but they later declined).  It eventually wound up I think, with Patient Care as a sponsor (a role that does provide project governance).

Attachments

I got to spend some time with attachments at their joint meeting in the Payer Summit and hear from Steve Posnack and folks from the CARIN Alliance, and where I popped in for a a few other meetings to hear what is going on.  Attachments is very closely following the Da Vinci project, so it is a good place if you aren't a member of the Da Vinci project to learn about what is going on there.  There are a number of payers and clearing houses working on Coverage Requirements Discovery, a topic I have some interest in.  It's basically a "pre-prior-auth" sort of specification, that basically allows a provider to ask a payer what data requirements a payer has to cover care for a given condition (including the need for a prior-auth, since there are no "standards" for what does require one).  FHIR has got payers excited, and for good reasons.  It's allowing them to modernize a HealthIT infrastructure that's long been in need of rejuvenation.

Da Vinci

Da Vinci has several projects going on.  I'm not specifically a member of the Da Vinci project (it too requires a membership fee, and I've got a limited budget).  Even so, many of the Da Vinci specifications are being balloted in HL7 projects, and you can follow them through their sponsoring workgroups, including:

• Electronic Clinical Data Exchange (eCDX) in Patient Care
• Document Templates and Rules in CDS
• Electronic Payer Data Exchange (ePDX) in Financial Management
• They are also looking for a home for the eHDX framework being used for eCDX and ePDX specifications (I haven't found this PSS on Confluence yet).

The eHDX project was discussed somewhat in the Patient Care joint meeting.

SD to be Cleaning up the Template Publication Format

Wednesday morning I found myself in a discussion of a topic that I complained about on Twitter and FB a year ago, the use of PDF (or other document formats for multi-ream documents (if printed).  SD won't do that any more after projects in flight are finished (you can't retroactively make a project do more work than they've committed to, HL7 would never get anything done, they learned that from V3).  I nudged that one along after Bret complained ("can you perhaps state that as a motion"), which I quickly seconded.  We spent a lot of time working out the exact wording of the motions, and the follow-on details, but just about everyone was on board with this. 

Technically, this is not as huge a challenge as it once was.  Later in the week Structured Documents assimilated the Templates workgroup, and the FHIR StructureDefinition and ImplementationGuide resources can handle most of the heavy lifting publication needs that the former V3 Templates specification was supposed to help with.  Between the publication of CDA R2 as a StructureDefinition, and the aforementioned resources, CDA templates can be published using FHIR IG tooling with perhaps some modest changes being needed.  I'm still using Trifolia as my de-facto reference for C-CDA templates until HL7 fixes this problem.

HSP Marketplace

No plan stays the same once the battle is engaged, and I found myself in other places, most notably a quarter with the SOA workgroup "battling" out my feedback on the Health Services Platform Marketplace negative.  As battles go, this one was mild, since the workgroup took most of my feedback into account.  The biggest discussion was around Chapter 4, the API, in which my major comment was simply put: "Use API documentation tools to document the API", and "describe your concepts better", again, they agreed in general, and we spent most of our time arguing the specifics.  The HSP Markeplace is shaping up, but I think it still has a long way to go.

V2 to FHIR

I also spent time with Orders and Observations (a.k.a, O&O, or simply OO), on the V2 to FHIR specification.  I spent the last half hour of one meeting unsuccessfully trying to find out what was going there and failed due to agenda overload, but DID get a good overview Wednesday afternoon.  This one has meat on its bones, and offers incredible value as Healthcare organizations figure out the many and various ways to get data into FHIR format.  I also spent Thursday morning 7-8am with several supporters of this project to talk about the tooling needed for this specification.    We agreed in principle to use the FHIR ConceptMap or StructureMap to capture the results of this effort, so that the end result will be computable. I am clearly going to be spending more time with this group, as this is directly related to my current work.

What I Missed

I had plans to spend time with both the Clinical Decision Support and the Clinical Quality Information workgroups this time around and failed because a 30 minute diversion (SOA) turned into the entire quarter, and OO's V2 FHIR project was more immediately compelling.  The case for cloning is never stronger than attending an HL7 Working group meeting.  I also missed out on some discussions in Public Health (formerly Public Health and Emergency Response, but the latter simply folds into the former), and Infrastructure and Messaging (InM) [which simply had nothing on their agenda to which I needed to pay immediate attention].  I'm certain I'll have to spend time with these groups at future meetings.

     Keith

It's not time ...

As I write this, I am preparing to head off to Chicago to see my good friend and colleague, Charles Parisot, and also do something I very rarely get to do, which is sit in a room with him for several hours while he listens to other people speak.  I'm second or third up on the roster to roast him, and we will have hours yet after I speak for others to say more about Charles, who he is, what he has done, and so on.  In fact, we have about as long as a normal post meeting conversation with Charles to say it all, which in fact will barely be enough.

Rather than talk to you about what Charles is though I will get to that, I want to start with a few things that he isn't.  First of all, he is not a planetary body.  Yes, Charles does have a gravity well (it's pretty deep), and he does have an orbit.  In fact, he mostly fits all of the modern characteristics defining a planet:

1. He orbits the sun,
2. He is not a satellite ... for anyone or anything,
3. He has cleared his own orbit by repeatedly brushing aside all obstacles, and finally
4. He does have sufficient mass to be mostly round.

He even fits the definition for the old Greek term, which essentially means wanderer, and he certainly is a wanderer.  But, he is not a planet.  The reason I know that Charles is not a planet is because he fails under one very conspicuous criteria, which is that he has an event horizon, and should you get too close, you will never escape it.  Any the only things known to date which have an event horizon are black holes, former suns or larger bodies which cannot, by definition, be planets.

He's also not Carmen San Diego.  Yes, you can find him wandering all over the world, but that's the point.  You CAN find him.  All you need do is listen closely and head towards the action, or at least the action as it relates to Healthcare IT.  When I used to be in more regular touch with Charles, often the first question I would need to ask, is where are you today, even if I spoke to him yesterday.  Twice, without even knowing beforehand, I simply asked hum which ministry call he was on this morning and twice he met my expectations, although in all fairness, it was only one of those days that he was testifying to Parliment somewhere.

Charles does not sleep, except perhaps on long-distance flights.  I know this because I've gotten e-mails from him at all times of day, and so have you.

Charles doesn't do any real work.  That's what his gravity well is for.  Should you happen to get sucked into it, you will do the work.  Charles will just sit back and do what he likes to do, which is talk, and argue.  Charles will talk for so long, you will agree to do just about anything for him just in order to get some peace.  But if he doesn't do any work, how does he get so much done?  See, that's just the point.  Charles doesn't create projects, he co-opts them, often several at a time.  Then he puts them into a big bucket, stirs them up, and watches as things magically arise from the bizarre concoction of ideas.  Charles doesn’t have a say-do ratio, in fact he completely destroys the concept of say-do ratio, because no matter how much he speaks, what comes out of it is clearly more than what went into it.  It’s more like the ratio of aleph null to aleph one.

Charles is neither a noun, or a verb, although he has been used in both senses.  You can pull a Charles, or Charles someone.  Charles is also not an unstoppable force, he can be moved, but his reaction to outside influences is quite confusing, more like a centrifuge or gyroscope.  When you try to push Charles in a particular direction, be very wary, because his response will often be at right angles to the direction of the applied force.  Be very wary when he agrees with you (especially completely), because that often means you are about to be the recipient of a perpendicular reaction that is completely unexpected.  This is what it means to have been Charles'd.

The last thing I will say about what Charles is not is that Charles is almost certainly not retired.  We here all know that he will be continuing to pop up in our lives, perhaps in even new and more interesting ways, now that he will soon be removed from the restraints placed upon him by his current employer.  I'm certain we will all continue to see him, because fortunately or not, we are all inside his event horizon.

OK, I lied.  That was not the last not.  Charles is also not a recipient of the Ad Hoc Harley award.  But as to what he is, and I did say I'd get to that, is certainly overdue for induction into 2018 class of the Lords and Ladies of the Ad Hoc Harley.

Charles Parisot

Semper et semper ascendens deinceps

(ever and ever riding forward)

Deep, Significant and Detailed HL7 Contributions

One of the points of the Ad Hoc Harley award is to recognize unsung heroes in heath IT standards. Almost all past awardees have been people I've worked with directly in standards development. While I have met the current awardee in person we've not spent much time collaborating on anything together, even though he's a fellow New Englander. Even so, I've still benefited from his work in standards, and his open source contributions.

According to two very smart people I know (one a past awardee), he's one of the smartest people they know. In addition to being a brilliant computer scientist [an assessment I heartily agree with having read, used and tweaked his code], he is also an accomplished singer who can harmonize with anything, a person of great humility, and a devoted family man.

While he was unable to be at the HL7 Working group this week, his work was demonstrated in several committee meetings.

His contributions include:

• CQL
• CIMPL
• CDS Connect
• Maintenance of the Quality Data Model
• Invaluable feedback on the CDC Opioid prescribing guidelines.
• Synthea’s Generic Module Framework

Without further ado:

This certifies that

Chris Moesel of MITRE

has hereby been recognized for deep, significant and detailed contributions to HL7 standards.

HL7 FHIR Proficiency Exam

Take the HL7 FHIR Proficiency Exam and get acknowledged by HL7 to be:

Prove your proficiency with the HL7 STU3 FHIR Specification.  Become identified as an individual with FHIR proficiency.  Employers, vendors and providers, help HL7 to influence the quality of the FHIR workforce.

Note: This is Proficiency exam rather than  a professional implementation credential.  HL7 is in the planning stages of a full professional certification

Competencies Tested

It's about breadth rather than depth:

• FHIR fundamentals
• Resource Concepts                                                        
• Exchange Mechanisms (includes RESTful API)     
• Conformance and Implementation Guidance     
• Terminology
• Representing healthcare concepts using FHIR resources
• Safety and Security
• The FHIR Maintenance Process
• FHIR licensing and IP      

Do you want to be part of the pilot?

The test is currently being piloted, and is currently available for a limited time to a limited number of individuals.  Space is very limited, so get it fast.

• Help HL7 improve the test
• Be one of the first to be certified

Registration and logistics

http://www.hl7.org/implement/certification.cfm?ref=banner

Pilot Test: What to Expect

• Online –  at test centers, or remote.
• Closed book
• 2 hours to complete 50 questions
• Multiple choice, multi-select, and true/false.
• No penalty for guessing.
• Passing score (for the pilot) 70%
• Cost $20 for members, $40 for non-members (for the pilot only).

How to prepare

Obtain HL7 FHIR Proficiency Study Package

• Guide + Practice Test
• https://www.pathlms.com/hl7/courses/4991

Study FHIR STU3!

This test was made possible by:

Grahame Grieve

Brett Marquard

Brian Postlethwaite

Bryn Rhodes

David Hay

Ewout Kramer

Eric Haas

Virginia Lorenzi

James Agnew

Josh Mandel

Lloyd McKenzie

Rob Hausam

Simone Heckmann

Viet Nguyen

Mel Grieve

The Good, the bad and the ugly (HL7 Ballots)

HL7 Balloting just closed this last hour.  Here's my recap of what I looked at, how I felt about it, and where I think the ballot will wind up from worst to best.  Note: My star ratings aren't just about the quality of the material, its a complex formula involving the quality of the material, the likelyhood of it being implemented, the potential value to end users and the phase of the moon on the first Monday in the third week of August in the year the material was balloted.

VMR (Virtual Medical Record) ⋆

1. HL7 Implementation Guide: Decision Support Service, Release 1 - US Realm (PI ID: 1018)
2. HL7 Version 2 Implementation Guide: Implementing the Virtual Medical Record for Clinical Decision Support (vMR-CDS), Release 1 (PI ID: 184)
3. HL7 Version 3 Standard: Decision Support Service (DSS), Release 2 (PI ID: 1015)
4. HL7 Virtual Medical Record for Clinical Decision Support (vMR-CDS) Logical Model, Release 2 (PI ID: 1017)
5. HL7 Virtual Medical Record for Clinical Decision Support (vMR-CDS) Templates, Release 1 - US Realm (PI ID: 1030)
6. HL7 Virtual Medical Record for Clinical Decision Support (vMR-CDS) XML Specification, Release 1 - US Realm (PI ID: 1016)

This had a total of six artifacts on the ballot.  Together they get 1 star for being able to pass muster to go to ballot.  As a family of specifications, this collection of material looks like it was written by a dozen different people across multiple workgroups with three different processes. What is sad here is that the core group of people who have been working on this material for some time (including me) is the same across much of this work, and it all comes out of the same place.  VMR was always an ugly stepchild in HL7, and these specifications don't make it much better.  Don't lose hope though, because QUICK and CQL are significant improvements, and the FHIR-based clinical decision support work such as CDS Hooks is much more promising. All appear to have achieved quorum and seem likely to pass once through reconciliation.

Release 2: Functional Profile; Work and Health, Release 1 - US Realm (PI ID: 1202)  ⋆⋆ 
Yet another functional model.  Decent stuff if that is what excites you.  I find functional models boring mostly because they aren't being used as intended where it matters.  Pretty likely to pass.

HL7 Version 2.9 Messaging Standard (PI ID: 773) ⋆⋆
The last? of a dying breed of standard.  Maybe? Please? Not enough votes to pass yet, but could happen after reconciliation (which is where V2 usually passes).

Pharmacist Care Plan  ⋆⋆

1. HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm (PI ID: 1232)
2. HL7 FHIR® Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm (PI ID: 1232)

Another duo, missing the overweight architectural structure of VMR, but certainly adequate for what it is trying to accomplish.  The question I have hear is about its relevance.  Except in inpatient settings, I find the notion of a pharmacist care plan for a patient to be of very little value at this stage.  In fact, we need more attention on care planning in the ambulatory setting.

These are for comment only ballots and the voting reflects it.  While not likely to "pass", the comment only status guarantees that these will go back through another cycle.  Based on the voting, the material needs it.

HL7 Guidance: 
Project Life Cycle for Product Development (PLCPD), Release 2 (PI ID: 1328)  ⋆⋆

HL7 continues to ballot its own processes.  What makes this one funny is that this particular ballot comes out of a workgroup in the Technical and Support Services steering division, which previously rejected another group in that divisions balloting a document because T3SD (their acronym) doesn't do ballots (BTW: That's a completely inadequate summary of what really happened, some day if you buy me a beer I'll get _ and _ to tell you the story.  Better yet, buy them beers).

It's a decent document, and likely to "pass".

HL7 CDA® R2 Implementation Guide: 
International Patient Summary, Release 1 (PI ID: 1087) ⋆⋆⋆
I could get more excited about this particular piece of work if it weren't for the fact that it's all about getting treatment internationally, rather than being an international standard that would eliminate some of the need to deal with cross border issues.  But, it's the former rather than the latter, so only three stars.  A lot of the work spends time dealing with all the tiny little details about making everyone happy on every end instead of getting someone to make some decent decisions that enable true international coordination.

This one is tight, will likely pass in reconciliation, and is getting a lot of international eyes on it.  It's good stuff.

UDI Implementation: ⋆⋆⋆⋆

1. HL7 Domain Analysis Model: Unique Device Identifier (UDI) Implementation Guidance, Release 1 (PI ID: 1238)
2. HL7 CDA® R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes; Unique Device Identifier (UDI) Templates, Release 1 - US Realm

By itself, neither one of these might have gotten four stars.  Together they do.  UDI needs a lot of explaining for people.  These documents help.

While the balloting looks tough (the second document is "failing" to pass by a 2/3 majority), it's all about doing what DOD, VA, and others want to ensure interoperability between them.

HL7 CDA® R2 Implementation Guide: 
Consolidated CDA Templates for Clinical Notes; Advance Directives Templates, 
Release 1 - US Realm (PI ID: 1323)  ⋆⋆⋆⋆

This is a useful addition to what we can do today with Advance Directives, and a great example of how to deal with backwards compatibility right, and they almost nailed it perfectly (my one negative comment on this item is a fine point).

Not a lead-pipe cinch but surely the issues in this one will be resolved during reconciliation.

HL7 CDA® R2 Implementation Guide: 
Quality Reporting Document Architecture Category I (QRDA I) Release 1, 
STU Release 5 - US Realm (PI ID: 210) ⋆⋆⋆⋆
Useful, necessary, and boring, but of great value.  Sometimes it pays to be boring.
Definitely a lead-pipe cinch to pass.  Third highest in positive votes, with 0 negatives.

HL7 Cross-Paradigm Specification: 
Allergy and Intolerance Substance Value Set(s) Definition, Release 1 (PI ID: 1272) ⋆⋆⋆⋆⋆
ABOUT. DAMN. TIME. An allergy value set we can all use. Nuf said.
The interesting back story here is who is voting negative (who cares) about this.  It looks like a lot of VA/DOD interoperability is going to get decided through standards. I'm pretty certain this stuff is going to get worked out, which has tremendous value to the rest of us.

HL7 FHIR® IG: SMART Application Launch Framework, Release 1 (PI ID: 1341) ⋆⋆⋆⋆⋆
I spend the most time commenting on this one.  I'm looking forward to this seeing this published as an HL7 Standard and in getting some overall improvements to what I've been implementing for the past year or so.

There's definitely some good feedback on this ballot (which means likely to take a while in reconciliation), even though it seems very likely to pass.

HL7 Clinical Document Architecture, Release 2.1 (PI ID: 1150) ⋆⋆⋆⋆⋆
This was the surprise of the lot for me.  I expected to be bored, having said CDA is Dead not quite four years ago.  I was, pleasantly so.  There was only one contentious issue for me (the new support added for tables in tables). They got to four stars by making sure all the issues we've encountered over the past decade and more were addressed. They got an extra star by making it easy to find what had changed in the content since CDA R2.  All in all, a pleasant surprise. CDA R2 still reigns supreme, but I think CDA R2.1 might very well become regent until CDA on FHIR is of age.
Oh yeah.  It passed, so very likely to go normative, which will make discussions about the standard in the next round of certification VERY interesting.

   Keith

The Value of Standards Maintenance

We recently looked at two fairly simple issues on the DSTU Tracker on CCDA 2.1 in Structured Documents.  I thought I'd take the opportunity to break down the cost of this sort of effort.

To establish costs, we first need to establish the cost for one of the people involved.  Some of the effort in maintenance is discovery and diagnosis within an organization of an issue that needs to be raised up to the maintaining organization.  For US developers, I use an estimate of about $75/hr in costs, which averages over a range of salaries from Junior to Senior developer.  For senior staff, (architects, analysts and others) involved in HL7 standards calls, You can double or triple that, because these staff are much more senior.  I'd call it about $200/hr for that group.

On today's call, we addressed two simple issues.  Each of these issues likely involved about 4 hours of development time, 3 to analyze and assess, and 1 to convey the resulting problem to the organizations HL7 representative.  That representative has about two hours of preparation effort associated with each issue, 1 hour to learn and assess the issue with their developer, and another hour of research into the issue, resulting in the development of a change proposal.  Each issue took about 15 minutes to discuss, assess, and agree to a change on the call, with 24 people on the call ($4800/hr!)

4.0   *     75 =   300
2.0   *   200 =   800
0.25 * 4800 = 1200
------------------------
                      $2300

So, for the two issues we addressed today, the approximate cost was almost $5,000, and these were SIMPLE ones.  More complex ones take much longer, often two or three committee calls, sometimes with the committee spending as much as two hours on the issue before coming to a resolution, and in many cases, between committee review, there's a smaller workgroup assessing the issue and proposing solutions (call it five people), which usually spend 2 or more hours on the topic ($1000 or more).

So, a single issue has a cost born by industry volunteers ranging from $2,300 to as much as $15,000.

Consolidated CDA has 255 comments against it today, each of which has been addressed at some point by the working group.  The value of this maintenance ranges from $0.5 to $3.8 million!

To come to a more precise estimate, we have to estimate how many of these issues fall into the easy category, how many fall into the hard, and how many are somewhere in between.  I'd estimate about 10% of issues are in the difficult category, about bit more than half in the easy category, and the rest somewhere in the middle (which I'd estimate costs about $6K).  It works out to about $2.1M for maintenance of CCDA 1.1.

   Keith

Apple IOS10 to support HL7 CDA in HealthKit

This is pretty big news from Apple for HL7, and something I'm rather feeling a bit proud of myself, even if I only played a small part in getting us to this stage.

Thanks to Andy Stechishin of the HL7 Mobile Health Workgroup for spotting this one and bringing it to the attention of HL7 Membership.

   Keith

P.S. Now if we can get the technology giant to pay attention to FHIR, my day will be made.

The battles of Relevant and Pertinent

In the year+ since we started the Relevant and Pertinent project, I've relearned many lessons that would have been readily apparent had I come from a military background. Two of these stand out in my mind:

No battle plan survives past first contact with the enemy.  

What we planed, and what I expected we would execute has gone through many iterations.  So far though, our general strategy has remained: Provide tools to enable developers to ensure that providers aren't overwhelmed by data that is neither relevant nor pertinent to what they are doing.

Never give an order that you know won't be obeyed.

One of the biggest debates we've had in this project is what to do when we've decided that something isn't relevant. The main concern was related to unintended consequences. What if ... we don't send it and it was important ... what if ...

So, we've decided not to decide what to do.  Instead, what we will do is provide rules for assessing he relevance and pertinence on a very coarse grained scale:

• More Relevant
• Somewhat Relevant
• Less Relevant

The data bears out fairly well that there are three clusters of relevance, and that clustering is somewhat insensitive to the provider experience with CCDA documents.  It's hard to argue with that.

In this, we follow the advice of Sun Tzu: 

The supreme art of war is to subdue the enemy without fighting.  -- The Art of War

We will provide some suggestions of different ways to use these assessments to avoid overwhelming providers with too much information, but these won't be requirements of the informative document, merely some things to consider.  Thus, we avoid the battle.

I'm fairly hopefully that we can shortly get to the point of Mission Accomplished.

   Keith

Relevant and Pertinent meets Acute/Chronic, Active/Inactive/Resolved and Current/Historical

We held our first Relevant and Pertinent meeting in several weeks due to some scheduling challenges, which resulted in some interesting thinking about what our output is going to look like.  We've stopped focusing so much on whether a decision that something is relevant affects what is done in the send or on the receive side.  It's a judgement, an assessment, a category that can help decide how to do something innovative to make information more useful.

I think people will argue less about the result because they will be less worried about unanticipated consequences.  Making an assessment about the relevance of a thing becomes a point of information that can be acted upon within an exchange, but it need not prohibit information from being exchanged, we leave that in the hands of the users of that assessment.  In some ways, it's very much similar to how saying "this information is sensitive" helps make access control decisions.  The assessment of sensitivity can be agreed upon if we can separate that assessment from access control consequences that we might not agree with.

In drilling down into this, we came up against one of my first deep discussions on problem classifications.  I was looking at the "Problem Status" vocabulary of CCR at the time:  Active, Inactive, Chronic, Intermittent, Recurrent, Rule Out, Ruled Out, Resolved.

What a basket of stuff, crossing at least three different classification boundaries.  Since then, we have probably all come to understand acuity, activity, and temporality as being three distinct axes of classification.

An acute condition is typically active or resolved.  A chronic condition is either active, inactive (I think I prefer managed), or in some few cases, resolved.  Chronic lower back pain is something that I suffered through for about a 12 month period, but it did eventually get resolved.  Other cases (specifically dealing with chronic disease states), rarely occur, but have been known -- often due to radical intervention.

This then gets into the question of relevance.  What is relevant about my chronic lower back pain, vs. my acute lower back pain, and how could one automate distinctions.  Let me propose that the following is a true statement:

What is relevant about a condition is all data related to that condition over the history where it has been present.  The data relevant to the acute lower back pain covers the period from which the problem was discovered to when it was last active and shortly thereafter.  The same is true for the chronic lower back pain, it's just that it's "active" history might be much longer.  Now, if you link diagnosis and treatment to problems (in a problem oriented medical record), you can now determine what treatments and diagnostics are perhaps "relevant" when considering lower back pain, regardless of chronicity/acutity.

I think we'll next need to get into a discussion of current, recent and historical.  Current is thought of in the now, but is actually in the very short term past, as in just happened.  Recent is a slightly longer window, perhaps measured in the context appropriate to the situation.  When one asks what my recent immunizations are, the context is a little bit different from when was my most recent blood glucose. Both are thinking about "most recent last", but not just now events.  The time context window is different for one rather than the other.  If you wanted to know when my most recent TDAP was, you might look back 5 years before saying, "That's far enough! You need a new one," whereas for blood glucose, you might go back as far as a year.  In both cases, anything before those dates is "historical" because it doesn't matter how far back after that time frame, its relevance is about equal (time for a new one).

The locus of focus may also affect our perception of relevance.  At the time of a visit, attention is on the condition that the patient is being treated for, the chief complaint or reason for visit.  For another whose attention is on that visit (locus), their attention (focus) may be elsewhere.  In communicating forward in time we usually assume that our focus will match that of the receiver, and so would determine relevance based on that focus.   We often discover that what appeared to be inconsequential then is more important now.

We have no way to predict the future, which results in the fear that a determination of relevance could prevent something that could/should have been communicated.  If, however, we can, as I would, put a protective force bubble around "what to do with the determination" as being subject to use-case appropriate judgement, we might come to dramatic consensus on what is "relevant" as best we are able to determine.


    Keith

Built in, not bolted on

Walking through HIMSS you can find a lot of products that "support interoperability."  Many are little more than some variation on a data transformation engine, perhaps combined with some form of database storage.  As a technology user, these bolt on solutions might look like the perfect way to fix the lack of interoperability in your Health IT infrastructure.  With one purchase, you too can solve all your interop issues.

We all know what that is.

So what is one to do? Here are some of my tests for interoperability solutions: Does your vendor know more than just the letters, H-L-7, I-H-E, or F-H-I-R? Ask them if they've ever sent someone to a connectathon or and IHE or HL7 meeting.  See if they even know and can list some HL7 standards or profiles. Do they know that a CDD or CCDA is based on CDA and that is based on HL7 version 3 and X-M-L?  Can they unparse these acronyms, or do they have someone in there booth that can?

If not, be careful, they might just be full of it, and you might be stepping in it.

If you want to see interoperability that works, come on down to the Interoperability Showcase, where you can see products from different and competing vendors working together.  You won't see that anywhere else on the show floor

Help HL7 improve clinical information exchange

If you are a healthcare provider (physician, physician assistant, nurse practitioner, nurse or other licensed provider), HL7 would like to hear from you about the information you think is relevant and pertinent to exchange in support of continuity of care.  If you want to participate, all you need to do is take a short survey.  You will need to act quickly. We are trying to gather this data before the end of the year, and due to the volume of provider responses, we are expecting to close the survey at the end of November.

We are planning on using your responses to develop an HL7 informative publication on what sort of information should be included in clinical summaries.

The slide presentation below explains the purpose of this project in more detail.  If your organization would also like to participate more deeply, there is another opportunity as well.  We have a separate engagement process for governance groups such as your organization's Informatics steering committee to allow them to provide input as a consensus body.  If you want more information about that opportunity, contact me via e-mail.

Datuit asserts patent may be applicable to HL7 FHIR

In my inbox this morning.  I haven't read the patent yet, but the first claim may be very recognizable to anyone working in IHE in 2003 - 2007.

   Keith

---

Datuit, LLC has advised HL7 of a recent patent they’ve received that MAY be applicable to the Fast Healthcare Interoperability Resources (FHIR®) Protocol Specification. The letter from Datuit alerting HL7 to the patent can be found at http://www.hl7.org/downloads/?DBKSPatentLetter 

An abstract of the patent (US8931039) entitled Method and System for a Document-based Knowledge System is available at:  https://www.google.com/patents/US8931039

Section 16 of the HL7 Governance and Operations Manual (GOM) addresses patents, and section 16.03.02 requires members/participants to issue a letter of assurance to HL7 for any patent  or patent applications felt to be applicable to HL7 Protocol Specifications. The letter of assurance from Datuit can be found here: http://www.hl7.org/downloads/?DBKSPatentInformationSheet

HL7 is not responsible for identifying patents for which a license may be required to implement an HL7 Protocol Specification (Section 02.02) or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. HL7 Headquarters shall notify the membership via email of any patent claims leveled against the HL7 Protocol Specifications. This announcement fulfills HL7’s requirement to notify the membership of this patent.

Karen Van Hentenryck