FHIR Product Roadmap Jan 2017 update

This crossed my desk this morning via Grahame Grieve (HL7 Product Manager for FHIR).

   -- Keith

---

https://onfhir.hl7.org/2017/01/20/fhir-product-roadmap/

R3 plans

The FHIR project is presently finalising "STU3" (Standard for Trial Use, release 3). This 3rd major milestone is currently close to completion. We've been meeting in San Antonio this week to finalise ballot reconciliation, perform testing and quality activities, and we are now focusing on preparing the final publication package. Following our publication plan we expect to be publishing release 3 on or about Mar 20.

R4 plans

Once R3 is published, we will start working on release 4. The various committees that manage the different parts of Release 4 have been discussing their scope of work for R4, and planning their engagement and implementation activities to support that this week.

Some of the major things under consideration for Release 4:

<![if !supportLists]>·         <![endif]>Improvements across all domains

<![if !supportLists]>·         <![endif]>Cds-hooks integrated in FHIR Specification

<![if !supportLists]>·         <![endif]>Query language framework

<![if !supportLists]>·         <![endif]>Support for integrating research and clinical practice

The most significant change is that R4 is expected to be the first 'normative version'. It's important to understand what that means. We will continue to follow our overall maturity model, where content gradually matures through testing and implementation activities that demonstrate success in the real world. The end of the process is "normative" ("FMM level 6"), where the standard becomes stable, and breaking changes are no longer considered.

Only some portions of the specification are candidates for being normative. We are currently considering balloting the following parts of the specification as normative:

<![if !supportLists]>·         <![endif]>Infrastructure (API, data types, XML/JSON formats, conformance layer resources like StructureDefinition and ValueSet)

<![if !supportLists]>·         <![endif]>Administration (amongst others Patient, Organization, Practitioner)

We will continue to seek and receive comments about this. Some clinical resources may be considered, depending how implementation experience unfolds this year.

Overall planned R4 timeline:

<![if !supportLists]>·         <![endif]>Dec 2017: publish first draft of R4 for comment (finalise plans for normative sections)

<![if !supportLists]>·         <![endif]>Jan 2018: first R4 based connectathon(s)

<![if !supportLists]>·         <![endif]>April 2018: ballot R4

<![if !supportLists]>·         <![endif]>May – Sept 2018: ballot reconciliation

<![if !supportLists]>·         <![endif]>Oct 2018: publish FHIR R4

We will conduct a round of market consultations in Aug/Sept 2017 to seek comment on this timeline from the FHIR community.

Note that this timelines anticipates that we publish R4 in October irrespective of the outcome of the normative ballot. Anything that has not passed normative ballot will continue to published as STU. We are still working on preparation, quality and balloting processes to support the normative FHIR ballot.

Longer term, we anticipate following R4 with a roughly 18 month publication cycle, with increasing normative content.

Implementation Progress

FHIR is a specification for a common API for exchanging healthcare data between information systems. Any information system supporting the healthcare system can choose to implement the common API, and exchange data following the rules. FHIR enables a 'healthcare web' to exist, but doesn't actually create it.

HL7 is pleased to work on the FHIR specification with many hundreds of partners, who are all implementing the specification to exchange data in service of the healthcare needs to their enterprises, their customers, and, ultimately, patients. HL7 does not 'implement' the specification (other than various prototype/test services) – our partners and other healthcare services do.

Argonaut Project

One particularly important sub-group of the FHIR community is the Argonaut project, which is a joint project of major US EHR vendors to advance industry adoption of FHIR and we've had many questions about the Argonaut implementation timeline for EHR access. With regard to the Argonaut community:

<![if !supportLists]>·         <![endif]>The Argonaut STU2 specification for Common Clinical Data Set elements is close to being finalized and will be announced shortly.  The Argonaut STU3 specification for Provider Directory will be published after final balloting of STU3

<![if !supportLists]>·         <![endif]>Most Argonaut members who are certifying an API with ONC are using the Argonaut specification; most certifications are expected in Q1/Q2 2017

<![if !supportLists]>·         <![endif]>Software roll-outs have commenced — progress will vary depending on the vendor

<![if !supportLists]>·         <![endif]>It is presently unknown what the adoption rate by provider institutions will be — MU and MACRA in the US provide incentives to make a patient-facing API available by the end of 2017

<![if !supportLists]>·         <![endif]>Some of the Argonaut interfaces provide additional functionality not yet described in the Argonaut specification, but there is considerable appetite for additional services beyond what is currently available. The Argonaut project will be making announcements about its future plans shortly which will be announced in a press release, through collaboration channels, and at www.argonautproject.org

Semper et semper ascendens deinceps

Always and always riding forward.  If you remember the original reference, you know what's coming next.

I had the honor today of having Wes Rishel in my CDA, XDS and FHIR class today.  Wes was the guy that co-opted my skills for his workgroup (Attachments), and for HL7 as a whole.  He has had an outstanding career as an Analyst for Gartner, and is a past co-chair of the HL7 Organization.  Now retired, Wes is doing some side consulting work with his rural health exchange.  He's one of the examples that I hold up before me that tells me I'll never need to retire from doing what I love.

Ed Hammond is another young fellow at HL7 who's stamina is outstanding.  Ed has been a mentor to many in HL7 and I count myself also among his mentees.  Ed teaches Informatics at  Duke University, has the longest tenure on the HL7 Board of any known person, having reached the pinacle of leadership at HL7 as Cochair Emeritus.  He's been recognized in many other forums (AMIA for example).  He's so influentially involved in so many places I want to make a Cards against Humanity cards that says "It wouldn't be the same ______ without Ed Hammond."

Both Wes and Ed are hereby inducted into the 2017 class of the Lords and Ladies of the Ad Hoc Harley.

Wes Rishel and Ed Hammond

Semper et semper ascendens deinceps

(ever and ever riding forward)

  

And now you both can also add LLAHH (Ladies and Lords of the Ad Hoc Harley) after your names if you so wish.

---

P.S  Pictures don't lie. Ed never ages. He looks the same as he did in 1990.

The FHIR $relevant Query

So I finally got my implementation of the "$everything" query working on my HAPI Server.  I started this at the FHIR Connectathon whilst waiting for people to hit my server.  It was in response to a need I had to generate a f***-ton of sample data in FHIR for testing and documentations.

Basically I have a code generator that reads FHIR profiles.  It's smart enough to assist me in producing some cool stuff.  After I got done, I wondered what I should do with it.

Given that this week we are closing in on the Relevant and Pertinent ballot, I think I'll just throw it away (just kidding ... I'll keep it around for debugging purposes), but I think the next query I build will be the "$relevant" one.

Here's my initial take on what that might look like:
Allergies = any active allergies.
Conditions = any that have been active in the last 30 days
Medications = any that have been active in the last 30 days, or any that were discontinued for lack of effect or toleration.
Labs = Most recent result of any lab type in last year.
Procedures = last year history and any currently scheduled
Vitals = most recent set
Immunizations = Last year for non-pediatric patients, otherwise all.
Encounters = any upcoming and last 90 days.

What's missing here is probably the most recent clinical impression.

-- Keith

Healthcare Standards Blog in Feedspot Top 100 Healthcare Blogs

This showed up in my inbox yesterday.  I reposted here with Anuj's permission.

---------------------------------------------

Hi Keith,

My name is Anuj Agarwal. I'm Founder of Feedspot.

I would like to personally congratulate you as your blog Healthcare Standards  has been selected by our panelist as one of the Top 100 Healthcare Blogs on the web.

http://blog.feedspot.com/healthcare_blogs/

I personally give you a high-five and want to thank you for your contribution to this world. This is the most comprehensive list of Top 100 Healthcare Blogs  on the internet and I'm honored to have you as part of this!

Also, you have the honor of displaying the following badge on your blog. Use the below code to display this badge proudly on your blog.

Best,

Anuj

 Anuj Agarwal

 Founder, Feedspot
 Email: anujagarwal@feedspot.com
 Linkedin . Twitter

Faking it with the FHIR Basic Resource

The FHIR team created the Basic resource to support extensibility.  It works great except that HAPI only supports one read() method for each resource, and sometimes you have more than one thing for which you need to extend basic. For my needs, I've been looking at Account and Transaction (representing either a payment or a charge).  So, how do I use Basic to implement these non-FHIR "resources".

What I finally worked out was to use a named operation.

With one set of operation parameters, the operation responds as for FHIR Read and is idempotent.
With another set of parameters, it responds as for a FHIR Search (and also is idempotent).
With another set it would respond as for Create/Update, where the distinction between Create and Update merely depends on whether the resource included in the POST/PUT contains an identifier or not.

This gives the user of the profiled Basic resource an experience that is pretty close to what they would get with a true FHIR Resource (and consequently makes it easier to adopt new resources that have been profiled in this fashion).

   Keith

What is it?

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet 
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:cda='urn:hl7-org:v3' 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  version="1.0">
  <xsl:template match="/|cda:*|@xsi:type|text()|@*">
    <xsl:copy>
      <xsl:apply-templates select="cda:*|@*|text()"/>
    </xsl:copy>
  </xsl:template>
</xsl:stylesheet>

What is this small but useful beast?

What version of CCDA Document is this?

This is a question I get internally and externally all the time.  The answer is pretty straightforward. Look at the templateId elements underneath the <ClinicalDocument> element.  There will be at least two and possibly more.

If you see: <templateId root="2.16.840.1.113883.10.20.22.1.1" extension="2015-08-01"/>
you can be sure this document is a CCDA Release 2.1 or later.  It will also bear:

<templateId root="2.16.840.1.113883.10.20.22.1.1"/> indicating that it is backwards compatible with CCDA Release 1.1.  

If you only have one templateId where root="2.16.840.1.113883.10.20.22.1.1" and there is no extension (like extension="2015-08-01"), you have a CCDA 1.1 that hasn't been uplifted to CCDA 2.1 yet.

If you have a templateId where root="2.16.840.1.113883.10.20.22.1.1" but extension="2014-06-09" then you have CCDA 2.0 and it won't be backwards compatible with CCDA 1.1.

Now, what if you have a templateId with 2.16.840.1.113883.10.20.1?  Well, now were talking old-school CCD, first edition.  It's a fine thing that has mellowed with age.

What you really want to see is <Composition> or <Bundle> as your first element, in which case you might be dealing with CDA or CCDA on FHIR.

It's all very confusing, but not really.

Each of them provides a core set of data about the patient, and for every single one of them, it's pretty much the same set of elements.  Those you might call a Continuity of Care Record.  There are a lot of ways to write the XML, but in the end, the data is essentially the same.

   Keith

P.S.  Thanks to Corey Spears for taking up the challenge of answering this question on the Structured Docments workgroup.  I'd already half written this post when he responded.

What is in a name? CDA Document Types revisited

The CCD (Continuity of Care Document) was originally envisioned as being the HL7 version of the Continuity of Care Record, which originated from a paper form originally used in the State of Massachusessets.  Since then the name has become synonymous with Meaningful Use, and in many ways, burdensome communication.

Because after all, if what you are after is Continuity of Care, what information would you possibly omit?

Recently I'd been asked by John Moehrke what other document could be used to represent a summary of a single visit.  Providers have many names for these:

Visit Note is the most generic, and basically could mean any level of detail from a single line of text to a three page report on the patient's current condition.  It could mean any of the different kinds of notes physicians use.

History and Physical Note describes an encounter (ambulatory visit) in which a History and Physical Examination is performed.  This could represent something like what your provider would report for your annual physical examination, or prior to undertaking some specific health-related activity.  Often surgeons perform an H&P prior to surgery.  Newly expectant mothers undergo one often when they first learn of their pregnancy.  The H&P principally is describing the results of a physical examination where either something specific is being looked for (such as the reason for an undetermined illness), or where more generally an assessment of a patient's overall health is being done.  More specifically, H&P relates to a specific service performed and billed by physicians.  H&P is pretty typically used in cases where a healthy patient is having an encounter with a physician, and may also be used in other cases where nothing is obvious.  It is in some ways a fishing expedition.

A consult note represents a different kind of service.  In this case, an opinion is being sought about a specific situation.  Rendering that opinion may require a history and physical, or it may just require some very specific examinations.  When my wife was being evaluated for arthritis, the physician didn't perform all of the steps one would expect in a physical examination.  He didn't need to look at different body systems, he was just interested in two or three.  He applied a stethoscope to my wife's knee and promptly upon listening when she bent it indicated that she did indeed have arthritis,and so rendered his opinion.  After we had already gone to the trouble to procure expensive imaging of said joint which he didn't even need to look at (although fortunately it later did come in handy).

A progress note is simply an update about a patient's progress.  In ambulatory settings it is used to report on a patient's progress with particular treatment or disease that is being followed by a physician.  Often it is used in various ancillary "therapy" settings, such as Physical Therapy, Respiratory Therapy, Cardiac Rehab, et cetera.

If you want a note that summarizes what happened in an encounter, think about the principal service provided during that encounter.  The note will name it, and the provider will also bill for it.  If I had to pick just one of the three above, Consult note would be my choice, because a consultation can always include an H&P, but an H&P doesn't cover the wide variety of healthcare situations.

Then again, maybe we should stop trying to shoe-horn every healthcare visit into the same documentation template.  There's more to this world than nails, and not every problem needs a hammer.

   Keith

P.S.  I think its funny that almost nine years later I'm still talking about hammers.

Can a fetus have an MRN?

There has been some interesting discussion on HL7 PHER list related to birth and death reporting for newborns.  During the discussion the issue has been raised a number of times of whether a fetus / stillborn baby could have a medical record number.

From a technology perspective, there is no reason why this could not occur.  Some EHR's do have a requirement that a valid date be entered for DOB of a patient (how they handle John/Jane Doe's who cannot be identified I don't know), but that challenge can be overcome by some simple procedural expedients.

It's really more of a workflow/policy question/social issue.  You can assign an identifier to anything. There's no reason NOT to assign one to a fetus if necessary, as far as the technology is concerned. The real issues are those of workflow and policy, and policy are certainly influenced by current social issues.  Issuance of a medical record number for some could be used as validation of the "lifely-hood" of a fetus, which raises a number of legal questions that deeply concern policy people.

Policy can be both a great enabler and a great destroyer of interoperability.  HIPAA is both a blessing and a curse in this space: many would argue that the administrative simplification brought about by establishing standardization of transactions and code certainly improved interoperability in the EDI world, even though there is still a long way to go. However, that same law and subsequent regulation also caused the creation of local enforcement policies which to this day are still used to disenfranchise patients.

So, don't get confused between policy and technology.  If you needed an ID to be associated with a fetus for birth and death reporting, certainly it could be resolved using an MRN, AS FAR AS THE TECHNOLOGY GOES.  It isn't the limits on technology which are stopping anyone from doing so.