Could we do HQMF Using the FHIR DSTU Today?

I struggle sometimes coming up with content to write here, especially when I'm working on internal vs. external projects.  So just for fun I've come up with a little external project for myself that I can talk about here.  We'll see how it progresses, and eventually it may become a real project in HL7.

The project that I'm looking at is how to create a Measure Specification in FHIR.  Interestingly, some of the available components I need are already present in the specification.

Looking over the HQMF Release 2 Standard, I need resources to support the following major components of a measure definition:

HQMF Measure Document	FHIR Resource of Resource Component
/QualityMeasureDocument	Composition
./author ./custodian ./verifier ./participant	Composition.author Composition.custodian Composition.attester N/A
./controlVariable/measurePeriod ./subjectOf/measureAttribute	Observation Observation
./definition/ValueSet	ValueSet
/QualityMeasureDocument//MeasureDescriptionSection	Composition.section
/QualityMeasureDocument.//DataCriteriaSection	Composition.section
./definition	N/A
./*Criteria	Query
/QualityMeasureDocument//Population Criteria Section	Composition.section
Numerator, Denomonator ... Criteria	N/A
/QualityMeasureDocument/MeasureObservationSection	Composition.section
./measureObservationDefinition	N/A

The four missing pieces deserve some discussion.
./participant is a way in HQMF to describe the contributions of a participant that aren't in the role of author, verifier or custodian.  I'd handle that as an extension.

./definition isn't needed because of the way that Query works.  A criterion in HQMF uses Query By Example.  In FHIR, we'd simply describe the query that was supposed to be executed using the Query resource.  Because of the way that resource works, model defintions aren't necessarily needed, or can be virtualized in the way that the Query URI is specified to be indicative of what set of resources are being queried.  Each query results in the production of a list of resources which is used on either the PopulationCriteriaSection or the MeasureObservationSection.

The various ways to configure counters like InitialPopulationCriteria needs a new resource to perform AND/OR/NOT Boolean operations over the results of executing the various Query resources to produce a count.  These are essentially set operations, like union, intersection and difference.  There are a couple of ways to approach this.  Today, I could cheat this using the List resource and specifying codes that indicate how to compute a count using codes like Union, Intersection, and Difference, with the list references pointing to the queries to be performed.  In fact, there's no reason NOT to do this since, as far as I can tell, List codes aren't fixed by FHIR.

Finally, we come to the tricky bit, MeasureObservationDefinition, which specifies how to compute a measure such as average wait time in the ED.  There's no existing way in FHIR to specify computations, which is the same problem we had in HQMF Release 2.0, and sort of punted on it by adding Appendix C on Expression Languages to HQMF R2.  I'm going to take a pass on figuring that out right now, as it may require a FHIR-based RESTful service or a Computation resource or something else to do that.

What this tells me is that I could build an implementation guide today to express MOST of what would show up in an HQMF Release 2.0 based measure definition TODAY.  Expletive Deleted!  Did I just say that?  Yes.  I did.

I also think it would be possible to build a transform from an existing HQMF R2 measure into that.  It might not handle every last bit, and transforming from Data Criterion into Query resources would be the hardest part, so probably worth investigating first.

Oh, and BTW, this also means that FHIR could be used to support Query Health.

So the surprising answer is yes, we probably could do at least 80%.

    Keith

P.S.  One caveat is that the code:valueset=[id|uri] would need to be supported by a FHIR server.  This capability isn't in the DSTU, but I've asked for it.

The Atomic Optimization Problem

A decade and more ago I worked on XML software instead of Healthcare standards.  One of the projects I watched fail but didn't work on suffered from a major optimization failure.  Overall, the system design seemed OK, but it had one big problem. The fundamental mechanism by which information was stored was based on entities that were too small to optimize in the storage system.  Now if you know XML, you know that there are a lot of different ways by which you can identify each node in the XML tree, including storing the ancestor/child relationships, using XPath or XPointer to index nodes, et cetera. In this particular case, the XML tree was indexed by one of these mechanisms. And so was the schema for the XML generated. The beauty of the solution was that it worked for every XML tree, and arbitrarily complex schemas. The failure of this system was that all nodes in the XML tree were treated as equal, and there was NO way to optimize behaviors for different kinds of nodes or different schema structures which applied to each node.  So, there were huge performance problems, and the database needed to be majorly redesigned, which resulted in a huge amount of rework, and eventually, project cancellation.

Why this results in implementation failure is something that not everyone gets.  You see, optimization relies on being able to discern differences between different kinds of entities, and allows you to make implementation choices between representations that make some operations more efficient than they would be when other choices are made. For example, denormalization is something that database architects sometimes do to trade between storage space and speed.  The whole notion of a star schema is a specialized denormalization of data that supports hyper-fast query at the cost of storage.  However, when everything is the same, and the system has no way of identifying things that could be dealt with more efficiently, it becomes very difficult to optimize.

Systems based on simple atoms (doubles, triples, or quadruples) can be very efficient, because each atom is the same and you can always build bigger concepts on smaller ones. This makes for very powerful systems, but not always ones which handle the bigger concepts as efficiently as they could be handled.  Consider LISP (the CAR/CDR pair) or RDF (the subject-object-predicate triple) or even the HL7 RIM (act, participation, role, entity).  These models make for very powerful systems that are built on small (usually very small), quite efficiently handled atoms.  However, each large concept is built up on smaller concepts which are built up on smaller ones and so on.  So even though your "atom" is very efficient, the larger concept you have to deal with can rely on hundreds, or even in some cases, thousands of atoms.  And that is where the performance problem becomes nasty.

When the "schema" for the object is also represented in doubles, triples or quads, and the storage system always handles each one of those units the same way, you've lost all chance at optimization.  And while I know it can be done, I've seen few products that even try because this sort of optimization is truly a black art.

Even moving higher up the tree, as in the RIM, to act, participation, role, entity doesn't always cut it.  There's just too much variation in the details of act or entity (or other class) that are of varying importantance depending on what you are trying to do.

One of the things I like about FHIR is the fact that the atomic level is dealing with Resources, and that each resource can be separately optimized to meet specific implementation needs.  I think this is the right granularity for efficient implementations.  Granted, I know the existing open source FHIR servers are primarily using machine generated coded built from the resource definition tables in FHIR, but that doesn't stop someone from doing some decent optimizations on specific resources to meet an implementation requirement.  I would expect a number uses of FHIR are likely to start from existing database stores which are already (or hopefully so) optimized to meet specific implementation requirements.

IHE Patient Care Coordination White Paper Published

IHE Patient Care Coordination White Paper Published for Public Comment

The IHE Patient Care Coordination Technical Committee has published the following white paper for public comment in the period from March 28 through April 27, 2014:

* A Data Access Framework Using IHE Profiles

The document is available for download at http://www.ihe.net/Public_Comment/#pcc. Comments submitted by April 27, 2014 will be considered by the IHE Patient Care Coordination Technical Committee in developing the final version of the white paper. Comments can be submitted at http://www.ihe.net/PCC_Public_Comments/

FHIR & SOA Discovery Day

This showed up in my inbox today. I think it will be an excellent opportunity for early implementers of FHIR to learn more from each other ....

---

With the tremendous amount of implementation interest in FHIR, this specification has taken both HL7 and the broader health IT community by storm, exposing resources via REST and providing easy access to healthcare data.  Over the past several meetings, in discussions with key FHIR community stakeholders and members of the FHIR Governance board, what has surfaced is an awareness that the behavioral side of FHIR has not settled in on a consistent pattern.  In fact, there are many ways of applying FHIR in a behavioral context, and the SOA Workgroup has been approached to take a look at the alternatives and to relate FHIR to our SOA services and architecture.

The Discovery Day is part of an overall effort to identify an approach that exposes the benefits of a consistent behavior when implementing FHIR, and documents an approach for doing so.  This one-day event is intended to provide background information as due diligence as we undertake efforts such as:     

• Defining approaches to expose services in FHIR
• Determining the best approach to apply existing SOA patterns using FHIR
• Aligning how SOA can be combined with FHIR to allow for consistent implementation patterns

To understand “the art of the possible”, you are invited to attend or participate in the first-ever “FHIR and SOA Discovery Day”, to occur on Tuesday, May 6, during the Phoenix Working Group Meeting.   This special event has the following objectives:

• To identify early-adopters implementing FHIR with interest in shared services and SOA (particularly for more complex behavior)
• To review multiple case studies to identify common challenges and/or implementation patterns
• To provide an environment for community input/feedback on implementations (informal peer review)
• Provide to the FHIR community a better understanding of the benefits and touchpoints with defined SOA services
• To collect an evidence basis to inform and shape SOA work that relates to FHIR

Agenda

Qtr	Time	Topic
Q1	9:00a	SOA Workgroup Meeting with FHIR Governance Board (Working Session) Note:  This is not technically part of the “discovery day”, but all are welcome to attend.
Q2	11:00a	Welcome & Introductions
	11:10a	Context Setting, Goals, SOA Workgroup Macro-View
	11:30a	Presentation 1 (Short)
	11:45a	Presentation 2 (Long)
	12:15p	Presentation 3 (Short)
Lunch	12:30p	LUNCH
Q3	1:45p	Reconvene and Recap
	2:00p	Presentation 4 (Long)
	2:30p	Presentation 5 (Long)
Break	3:00p	Break
Q4	3:30p	Worksession & Discussion – What did we learn and how do we apply it?

How To Present:

Please send the following information to Ken Rubin (ken dot rubin at hp dot com) , including:

o   Project name / Presenter(s) / Organization(s)

o   Timeslot desired (short or long)

o   Brief Description of the Project

o   Brief Description of the Business Problem You were Addressing

o   Brief Description of the Technical Aspects of your project

o   Relationship to SOA (Optional)

o   Your recommendations to us, or challenges/concerns for us (Optional)

Submissions will be reviewed by the SOA workgroup and slotted based upon the total number of responses received and fitness to the objectives.   Ad-hoc presentations will be taken from the floor, time permitting.  All HL7 meeting attendees are welcome to join us.

Note:  Timeslots are intended to include time for Q&A.  We suggest 5 minutes of Q&A for short sessions and 10 minutes for long sessions.  Presentation allocation times may adjust based upon abstracts received.

Concerns in HL7

Quite a bit of time has been spent recently on many HL7 lists discussing the Concern act found in CCDA and prior specifications including the CCD, the IHE PCC Technical Framework and the HITSP C32.

This structure is based on the Patient Care Concern act, which went through "Harmonization" (The RIM modification process) in 2005/2006, but probably finished being implemented properly in the RIM sometime in 2010 or thereabouts (due to administrative rather than technical issues, and mostly dropped balls on the administrative side).

The Concern Act that the Patient Care Workgroup developed has a great deal of capability.  Current "concerns" among CCDA implementers and HL7 developers is that it is overkill for many uses, e.g., handling allergy lists.

Back in the day (2006) when it was first added to a CDA Implementation Guide (the IHE PCC Technical Framework was first to adopt it), the rationale for including it was to address two issues:

1. Tracking who added the item to the current (allergies or problems) list.
2. Tracking when it was added or removed.

Several have noted that this information also appears in audit logs, which is certainly a true statement. However, audit logs are not information items that are typically made available to normal users.

These two pieces of data have clinical significance.  The who tells you who added (or removed) the item from the list, so you can track down what happened.  This may be distinct from who made the observation (e.g., a DX of a disease may have come from another provider).

The question arose from Grahame's work on supporting CCDA capabilities in FHIR.  In looking through FHIR, there are two Resources of interest for Concern.  One is Condition, and the other is AllergyIntollerance.

In examining these two resources, they both support capture of "who recorded" the information and when, in the Condition case, called the Asserter, and in the Allergy case, the Recorder.  Condition also includes onset and abatement dates.  So it already has the necessary components needed to support the capabilities of Concern that are used in the wild to MY knowledge.  The allergy case is missing the onset/abatement dates, likely because of the [mistaken in my opinion] assumption that this is either not important, or that allergies never go away (Never and always are two dangerous words to use in Healthcare or in any other endeavor).  I can live without this capability in allergies because it can be added back through the extension mechanism.

So, to handle what is needed for CCDA in FHIR, applying the 80/20 rule, I'd just use Condition and AllergyIntollerance, and push all the concern pieces NOT present into extension.

    Keith

NOTE: In CDA and elsewhere in HL7 Version 3, Allergy is treated simply as a specialization of problem. While this makes sense to engineers, it makes little sense to many physicians.  This is in part why Concern is used in both places, but also because it supports the capture of information not found in Observation.

The next Ad Hoc Harley ...

The point of the Ad Hoc Harley awards is to recognize people who have accomplished something significant. In this particular case, I'm recognizing someone who has in a large part taken over one of what I have long considered to be "my job", and done so in a way that is both more complete, and better than the work that I do here on this blog.

Recently I added his work to my auto-tweet list, which is still a pretty short list. Anything he writes winds up getting distributed immediately.  What it takes to get on that list is the production of consistently high quality information that I think will be important and relevant to my followers, mostly people who are interested in what is going on in Health IT, especially HL7 and IHE.

His work is also featured on the HL7 Help Desk for Meaningful Use and has developed much of the content for that in HL7.  He started listening to the Structured Documents list about 21 months ago and his first post to the list was about 18 months old, with a very telling summary of the discussion on open versus closed templates.  This was our first example of his ability to summarize a long and involved discussion and engage with experts to make it easy for implementers to understand what is going on.

Without further ado, let me award ...

This certifies that 

Brian Zvi Weiss of CDAPRO 

For outstanding explanations of CDA and contributions to development of the HL7 Help Desk

A Final Post from Riyadh (for now)

Yesterday was a fairly busy day for me, being the last day of a 10-day trip to Saudi Arabia.  Last week I spoke at KSU on eHealth Standards (I'll update the link for the slides when I get it).  Yesterday I attended a seminar organized by the Saudi Association for Health Informatics held at King Fahad Medical City.  To topic of the lecture was Innovation, and the presenter was Dr. Bassam Al Hemsi, an OHSU Alumna.  Dr. Al Hemsi had invited me to the lecture that afternoon, and it was a tight squeeze, but due to the kindess of an MOH employee (Dr. Ayman BafaQeeh), I was able to attend.  The kindness and hospitality of the Saudi's I have met here is quite overwhelming.

Dr. Al Hemsi has an extensive history in Healthcare and IT, including 5 major facilities in Saudi and as CIO of the National Guard's health system.  He is a surgeon, informaticist and educator, and an innovator in his own right.  The key point of his presentation was to describe what it would take for Saudi to become an innovator in Health IT.  He talked about how People + Processes + Information + Technology become products and services, and illustrated some of his own work in the field.  He emphasized the difference between a Leader and a Boss, and emphasized the importance of being the latter to his audience.  He also emphasized the need to do, and even to make mistakes as being important to developing the skills necessary to succeed.  I quite enjoyed his presentation, even as I recalled the many mistakes I have made in my career that taught me so much.

I got to spend some time with Dr. Al Hemsi at his clinic before the presentation, where he kindly showed me some of the innovative things he had designed for use in his Hemodialysis Clinic.  It was pretty cool stuff. The most impressive item was a 110" multi-touch display he had built, including the software his team had designed to make use of it, but he has also designed several medical devices and innovative software using a digital pen for data capture that he also uses in his clinic.

Dr. Al Hemsi is a good speaker, and his audience was quite engaged in the topic.  It was very clear to me, especially in the educational settings that I have been in over the past ten days that the current crop of Health Informatics students and practitioners in Saudi are quite enthusiastic about eHealth and Standards.

   Keith