Models of Clinical Decision Support

This is mostly a thinking out loud piece for me to wrap my head around some thoughts related to the work that I've done on Clinical Decision Support, and how that relates to work done recently for the SANER Project, and how to connect that to ECR, and other public health reporting efforts. My first step in this journey is to review what I've already written to see how my approach to CDS, and that of standards has evolved over time.

Some of the more interesting articles I've written on this topic include:

• Clinical Decision Support (2008)
• Gozinta and Gozouta (2009)
• Declarative vs Procedural and Query Health (2011)
• Real Time Quality Measurement as Clinical Decision Support (2012)
• Gozinta and Gozouta meets Query Health  (2012)
• CDS on FHIR (2015)
• Hello CQL (2018)
• FluentQuery for FHIRPath (2020)

Most relevant to this discussion is the three legged stool of instance data, world knowledge, and computational algorithms from my first article.

The biggest difference in most implementations of clinical decision support is in where the algorithm gets executed, and quite a bit of effort has been expended in this arena.  I originally described this by referencing the "curly brace" problem of ARDEN Syntax, and it describes a challenge of integrating the algorithm for computing a response with a way of accessing instance data.

Here are the key principles:

1. Separate data collection from computation. (Instance Data from Algorithms)
2. Use declarative forms that can be turned into efficient computation (Algorithms).
3. Separate inputs from outputs (Instance Data, Actions and Alerts).

The tricky bit, for which I don't HAVE a principle is in how to identify the essential instance data, which honestly is largely driven by domain knowledge, and this is where MUCH of the nuance about implementing clinical decision support comes into play.  

There are two main approaches to clinical decision support: Integrating it "inside" an information system that has access to the essential data, or moving the data to an information system that can efficiently compute a result.

The former operates on the assumption that if you have efficient access to data, then compute locally (where the data results), and you can thus skip the need to separate instance data from algorithms that implement knowledge.  The latter requires the separation of instance data from the algorithm to facilitate data movement.

A large distinction between what SANER and Clinical Quality Measurement does from the rest of Clinical Decision Support is largely based on the distinctions between the needs for systems supported decision support based upon population data (data in bulk), and systems making decisions at the level of an individual.

It largely boils down to a question of how to access data efficiently. Different approaches to clinical decision support each approach this in a slightly different way.

• Quality Reporting Data Architecture (QRDA) defines a format to move data needed for quality measurement to a service that can evaluate measures.
• Query Health used Health Quality Measure Format (HQMF) to move a query described in declarative to a data source for local execution, and then results back to a service that can aggregate them across multiple sources.
• HQMF itself has evolved from an HL7 Version 3 declarative form to one that is now largely based on the Clinical Quality Language (CQL) which is also a declarative language (and a lot easier to read).
• Electronic Case Reporting (eCR) uses a trigger condition defined using the Reportable Condition Mapping Table (RCMT) value set to move a defined collection of data (as described in eICR) from a data source to the Reportable Condition Knowledge Management Service (RCKMS) which can provide a reportability response including alerts, actions and information.  RCKMS is a clinical decision support service.
• CDS Hooks defines hooks that can be triggered by an EHR to move prefetch data to a decision support service using SMART on FHIR, which can then report back alerts, actions and other information as FHIR Resources.
• SANER defines an example measure in a form which is represented by an initial query, and then filtering of that, using FHIRPath, which may result in subsequent queries and filtering.

One of the patterns that appears in many CDS specifications is about optimization of data flow.  There's an initial signal executed locally, which is used to selectively identify the need for CDS computation.  That signal is represented by a trigger event or condition, driven by either workflow, or a combination of workflow and instance data.  One example of a trigger event is the creation of a resource (row, database record, chart entry, FHIR resource, et cetera) matching a coded criterion (e.g., as in RCMT used with RCKMS for ECR). 

The trigger/collect/compute pattern is pervasive not just in clinical decision support, but in other complex (non-clinical) decision support problems that deal with complex domain knowledge.  It has uses in natural language processing software, where it has been used for grammar correction, e.g., to detect a linguistic pattern, evaluate it against domain (and language) specific rules, and then suggest alternatives (or verify correctness).  The goal of this approach is multi-fold: optimization of integration and data flow, and separation of CDS logic (and management thereof) from system implementation.

Population based clinical decision support is often expensive because it may require evaluation of thousands (or hundreds of thousands) of data records, and the more than can be done to reduce the number of records that need to be moved, the more efficiently and quickly such evaluations can be performed.  FHIR Bulk Data Access (a.k.a., Flat FHIR) is an approach to moving large quantities of data to support population health management activities.  It further accentuates the need for optimization of data movement to support population management.

As I think again through all of what has gone before, one of the things missing from my three legged model is the notion of "triggers", and I think these deserve further exploration.  What is a trigger event?  In standards this is nominally a workflow state.  From a CDS perspective, it's the combination of a workflow state, associated with resource matching a specific criteria.  The criteria is generally pretty straightfoward: This kind of thing, with that kind of value, having a measurement in this range, in this time frame.  And in fact, the workflow state is almost irrelevant -- but is usually essential for determining the best time to evaluate a trigger event.  Consider ECR for example, you probably don't want to trigger a reportability request until after the clinician has entered all essential data that you might want to compute with, at the same time, you don't want to wait until after the visit is over to provide a response.  Commonly this sort of thing might be triggered "prior to signing the chart", given that you want to make sure that the data is complete.  However, given that the results may influence the course of treatment or management, a more ideal time might be just before creation of the plan of care for the patient.

A few years back I worked on a project demonstrating the use of "Public Health Alerts" using the Infobutton profile and a web services created by John's Hopkins APL that integrated with an EHR system that was developed by my then employer.  We actually used two different trigger events, the first one being after "Reason for Visit" was known, and the second one just before physical exam, after all symptoms and vital signs had been recorded (if I remember correctly).  This was helpful, b/c the first query was relatively thin on data, but could guide data collection efforts if there was a positive hit, and the second one could pick up with a better data set to capture anything that the first might have missed.

I'm not done thinking all this through, but at least I've got a first start, I'm sure to write more on this later.

Shifting into Sixth Gear

1. Standards are like toothbrushes.  Everyone needs one, and everyone wants to use their own.
2. Standards are like potato chips.  You cannot have just one.
3. And then there's simply XKCD 927 (a well worn, perhaps even "standard" image in standards circles).

And if you look back to late 2012 and early 2013, you can see some of the discussions I had in this space around a battle between two competing standards from the same organization, one for Clinical Decision Support and the other for Quality Measurement.

What rarely happens in this space is that something new arises from the mess that actually solves two different problems ... in this case though they were two different sides of the same coin. The conditional: If (X) then (Y), and the measure: [patients for whom Y is relevant]/[patients for whom X is true].

What happened?  Clinical Quality Language is what happened.  And in the words of its inventor, "we started with an evaluation environment ... we already had the ELM infrastructure ... and we added an execution language".

Yes, I'm crediting one person for the invention because I watched how this played out, and while every standards effort is a corporate (little-c) one, this one was very much driven by one person which assistance from a cast of dozens and input from many more.  Much in the same way as FHIR was originally driven forward by Graham Grieve, but became an effort backed by many.

In fact, recently, CQL was recently recognized by CMS in the following fashion:

CMS Announces Transition of Electronic Clinical Quality Measures to Clinical Quality Language for the CY2019 Reporting/Performance Periods

So, for changing the paradigm in a big way, in fact, for being to CDS and Quality Measurement what Grahame Grieve was to FHIR, I'm awarding this Ad Hoc Harley as follows:

This certifies that  

Bryn Rhodes

Has hereby been recognized for changing the paradigm in Clinical Decision Support and Quality Measurement

P.S. Bryn and I are working two different tracks yesterday and today at the Digital Quality Summit in DC hosted by HL7 and NCQA.  It's no accident that I chose today to award this particular accolade, but Bryn's award was pretty much in the bag last month when I realized how long it had been since I issued one of these, and looked back at who I had missed.

CDS on FHIR

Yesterday I attended a meeting containing a blue ribbon panel of EHR and CDS standards geeks in a packed room at Children's Hospital, hosted by Josh Mandel, and attended by head FHIR chief Grahame Grieve.  Josh is probably the best example of a FHIR chief that we have in this country. His work on SMART is already being adopted by EHR systems and healthcare entities in this country. We talked about a new way to integrate clinical decision support into the EHR, which I'll describe below.

Essentially the idea is to have applications register with an EHR their desire to be notified at particular points in the provider workflow, and to request specific information be provided to them. Associated with the application registration are:

1. The service URL to invoke: [base]/$cds-hook
2. The identifier for the trigger event (e.g., medication-prescribe)
3. An optional pre-fetch template to obtain data to pass to the service URL in addition to the resource associated with the trigger event.

The service will pass back zero or more "action cards" which can be used to tell the EHR the advice given by the CDS service.  The EHR can decide on how to integrate that advice into the physician workflow.  You can find more details on Josh's wiki for the project.

This is quite cool, and works well with existing patterns of CDS use.  

1. Information action cards provide sort of an extended InfoButton capability.
2. Other action cards fit well within patterns established by FHIR Care Provision (e.g., ReferralRequest and ProcedureRequest), MedicationOrder, and Workflow (e.g., Order, DeviceUseRequest, SupplyRequest, etc.).
3. Still other action cards can integrate with a cloud-based or locally hosted HTTP service to provide additional user interaction, and be integrated into the EHR ala SMART kinds of interfaces.
4. Yet other action cards (discussed in the meeting, but not yet described on Josh's wiki) might support other capabilities within the workflow, perhaps to address the CDS integration itself. One example of this we discussed at the meeting was that when a service is not covered by a payer (as determined by one service), going into another service that looks at determining medical necessity might not be needful).

A couple of comments come to my mind when looking at this:

1. I'll bet I can find hundreds of trigger events and associated contexts for CDS from HL7 Version 2, Version 3, InfoButton, HITSP, IHE and other specifications.  This is more of a data mining exercise for trigger events than anything else.
2. Separately, each trigger event may want to be associated with one or more principle resources that describe the data associated with the trigger event.  For example, for the medication-prescribe event listed above, the likely candidate would be MedicationOrder.
3. The way that the pre-fetch template works is a quite generalizable mechanism that supports many different integrations.  

That last comment deserves a lot more expansion, because I think it is the keystone to advancement in many standards.

This mechanism generalizes specific templates for sending data for an integration.  For example, this is how IHE had previously integrated forms based data capture in the Request Form for Data Capture (RFD) profile, with the needs for specific data as described in the Clincial Research Document (CRD) profile.  A similar mechanism has been used by CDS implementors by providing recommendations based on the content of a Virtual Medical Records (VMR) delivered through a CCD document.  It would also work quite well to specify the data requirements for a quality measure. By "registering" the pre-fetch bundle with the EHR, the CDS system allows the "question" to come to the data (as we did for Query Health), and the EHR to decide (based on the policies of its organization) how to respond to this query.  

Fortunately, this meeting came at a time when both CDS and Clincial Quality Measures in FHIR are currently being discussed in HL7, and can so impact both of those activities prior to them becoming DSTUs.  I'll very likely be making this point next week at the working group meeting in Atlanta, but if I don't I can count on many of the luminaries in the room yesterday to also do so.

I was thrilled to be invited to this event, and am really grateful for Josh's continuing his past outstanding work.  He is clearly no "one-shot" wonder, and I look forward to his future contributions to the world of standards.

   Keith

P.S. One of the values we have in the "slow-down" of ONC on the development of standards is the luxury of time to do things right, instead of against an arbitrary deadline.  That makes me hopeful that CDS, instead of being the unfindable Holy Grail of EHR integration, would instead become a commonplace mechanism for building the best EHR system one could imagine.

I will not profile policy, I will not profile policy, I will not ... x100

I probably need to write this more than 100 times, since I wind up doing it so often.

We reviewed the work I had done on the GAO profile I talked about yesterday.  For a lot of what the CDS system needs to do, it is:

1. Not interested in certain details.
2. Would prefer not to know other details.

From an interoperability perspective, it can simply ignore #1, rather than having us profile them out.  For #2, there are questions of liability, in which the receiver really doesn't want to be responsible for dealing with someone else's PHI.

The first case represents the profile's lack of requirements or interest.  Rather than profile these out, we are going to identify those that are permitted by the profile, but which may be suppressed either by the sender or the receiver for business, security or privacy reasons.  These are mostly, in this case, business reasons.

The second case represents the receivers specific requirements in certain cases that some details not be sent, because they then become responsible for dealing with the content in ways that they would rather not have to.  In this case, we'd like the profile to support their use of the content, but we won't impose their policies for integration with their system.  Instead, we'll let them impose those policies. So here, we will identify those data elements for which their may be some concerns in the security considerations section, and note that receivers may prohibit use of certain data elements according to their own policy.

This greatly simplifies the profile.

Guideline Accountable Ordering

I've spent the last several days using HL7® FHIR® tooling to build the Guideline Accountable Ordering profile in PCC to go along with the CDS for Radiology work that is happening in that domain.  Imaging is the principle use case for this profile, given the need for CDS to be used on imaging orders paid for by medicare based on recent legislation [see section (q)] passed in the "Doc Patch" last year.

Building the profile is fairly straightforward, except that the build process is not really designed for single profile development. That will have to change at some point.  There are times when I have to wait 25 minutes to find out that I have another syntax error.

The basic outline of GAO is that there is a request, comprised of an order for a diagnostic test, and a response that indicates whether the order is appropriate.  The order at this stage is "proposed", not yet "requested", so that the ordering physician can be "guided" by the CDS implementation if he/she so chooses.

The order contains various pieces of data, including the ordered service, the identifier of the ordering provider, a timestamp, an identifier, and various data elements providing indications, reasons, and related clinical data that might help a CDS service determine appropriateness.  Little about the patient need be exchanged initially (e.g., gender and date of birth), and little detail about the service, it's code, a code for indications, and perhaps other data known to be necessary (patient weight might also be important for example).

The service can response with an affirmative "within guidelines" response, indicating that the order is appropriate (and which guideline it was evaluated against), a negative "outside of guidelines" response, or a "no guidelines apply" response, indicating that no guidelines are available to evaluate the request against.  The service can also provide a link to a request for more information, either as a questionnaire which can be responded to, or as a web based service which could be invoked to guide the clinician through more questions and answers (essentially the web-based implementation of the questionnaire).

Right now, I'm looking at the response which comes back.  The closest thing that I've found is the Provenance resource.  This is a bit of an edge case for provenance, and some have suggested that an "Authorization" resource might be appropriate.  This would of course have to wait for DSTU 2.1, so I'm going to stick with the present approach because it is fairly close to what we determined were our requirements.  If it turns out we need to change it, we can.

In the meantime, I'm going to go back to playing with this profile and the FHIR build tools.  I think my most recent build is finished.  I wish I knew why it keeps doing a full build every time.

     Keith

Clinical Quality Workgroup discusses Standards Selection Criteria for CDS and CQM

Today I got to present to the HIT Standards Clinical Quality Workgroup on principles for standards selection.  I had raised the point at our last meeting that it would be good if, before we started selecting standards, we actually understood the principles behind which such a selection was made.

A lot of work has already been done in this area, as I reminded the workgroup.  I started from first principles as to why consensus standards are desirable, moving to a derivation from NIST's Guiding Principles for Identifying Standards for Implementation as found in the Framework and Roadmap for Smart Grid Interoperability, and then on to principles found in HITSP's Tier 2 standards evaluation criteria, and the unwritten principles (now written down) for IHE standards selection, and the written principles for taking a profile to final text.

Then I gave an overview of the feedback I had received from many interested parties who responded to this post, or whom I found it interesting to talk to about the issue, including the guy who labels himself as "a dumb family doc" but is now sitting in the National Coordinator's seat (he wasn't at the time I asked). Next time around I get to summarize this into a strawman proposal for the workgroup (the reward for a job well-done is another job).

There was a really great question from the caller from AHRQ, which was related to the point I raised about what is our standards architecture for Meaningful Use. After all, if you don't plan one, it just sort of happens. I'm hoping we can discuss that on a future call. I have some idea about what sort of architecture could be extracted from that program.

The transcript will be posted later, and you can find the materials and a subsequent transcript of what was discussed on the HIT FACA Web Site. Here are my slides:


We took the list of specifications above, and parceled out the pieces into slide 5, and put it on a white board [this picture is after we cleaned it up].

As you can see, there is plenty of overlap.  We also noted quite a bit of gap, because we are missing (actually, it exists, but it's lore rather than publication) a lot of specifications where we agree (at the conceptual level). 

In fact, we agreed that at the conceptual level, we are almost in complete agreement.  The one place where we have some variation is between QDM and HL7 Clinical Statements, where there are some disconnects.  There is also a great deal of consistency at the platform independent information model level.

One of the realizations that I came away with was that in the RIM, the rules for interpretations for how to deal with certain structures in the RIM are behavioral/interpretation models ion the computation viewpoint space, rather than logical models in the information viewpoint (e.g., joinCondition has implied behaviors).

There's plenty of work to turn this diagram into an Architecture, and that's what I'll be spending the rest of my week on (when I'm not doing other things).

I was extremely pleased with how this workout went.  We had a room filled to the brim (nearly 50 people) who were writing on post-its and pasting them up on this diagram.  We came to an agreement on where we agree and disagree, and we have some plans for how to move forward.  And I totally was making this up as the week was proceeding, but it worked really well.

We still disagree on some things, but now at least, we have a much better idea about where.  There was a point in the meeting where someone was talking about one thing, and I disagreed, and then we clarified what boxes we were both talking about, and were instantly back in agreement.

Clinical Quality Workgroup

The Clinical Quality Workgroup of the HIT Standards FACA met today to discuss issues around the harmonization of information models and logic for expressing CQMs and CDS and readiness of those for use in the next stages of meaningful use.  While we could have dived right into various standards, I suggested that we first establish some principles around which we would be evaluating the standards and making recommendations.  So, I was asked to make a list of said principles.  I have my notions, but I'd like to hear yours.

Here are some examples:
1.  The standards should be aligned around a common data model.
2.  The translation from representation in one standard to the other should be obvious and non-ambiguous.
3.  Value sets should be able to be separately maintained.

If you have inputs, add them as comments below (here or on Google+), or e-mail me (you can find my e-mail address on this page).

    Keith

Can I ask You a MeaningfulUse Question on CDS and Imaging?

This question came in via Ask me a Question. Since 1) I'm on vacation and 2) I've little experience with Radiology workflows, I thought I'd see what crowd sourcing can do to get an answer.  Here is the question:

---

Hi Keith 

I was wondering if you had any thoughts how a vendor for a Radiology Information System program would implement clinical decision support for MU Stage 2. It seems like the MU CDS rules are geared more towards providers, in that it helps them decide on a course of action depending on a list of variables. However, when a patient arrives in a radiology department the decisions have already been made by the provider. There's not much else anyone in the radiology department can do. To make things even more difficult, the ONC's testing criteria "Test Procedure for §170.314(a)(8) Clinical decision support" states over and over that each CDS intervention be automatic and based on the patient's problem, medication, medication allergy, demographics, labs, and vitals. Like I said, all of those variables have already been sorted out by the time a patient has arrived in the radiology department, so do you have any thoughts on how a radiologist can incorporate CDS?

---

I have to agree that the rules are more geared towards traditional providers.  I also seem to remember a few cases where there were exceptions available when a provider did not directly interact with a patient, but I don't believe that was addressed in CDS.  And while I could look it up, I'm on vacation ;-)

So let me see what you can do to help this reader.  Please respond in comments below.

Real Time Quality Measurement as Clinical Decision Support

The topic of "Real Time Quality Measurement" as "Clinical Decision Support" has come up recently in three different forums.  In the AHRQ RFI which I mentioned earlier today, in a previous face-to-face meeting of the HIT Standards Committee, and just now in the agenda for the Clinical Quality Workgroup for tomorrow's montly call.  I'm a member of that workgroup, but won't be able to attend the meeting, given that I'm in an all-day training teaching about standards for quality measurement.  As always in cases where I cannot attend the call, I read the materials and respond ahead of time to the workgroup, so that at least they have my input.  After rereading, I decided to share it as this post:

On the topic of conceptualizing CDS as real-time quality measurement, you’ve hit one of my favorite discussion topics.

Quality measurement is intended for process improvement. One of the first steps in process improvement is documentation of quality processes. The second step is to build measurement into those processes so that progress against quality can be measured as early as possible. In clinical care, the process is a care guideline, and when that guideline is instrumented to that it can be measured, it can also be instrumented so that it can be executable. An executable clinical guideline operating against measurable inputs is clinical decision support in a very real sense.

My post on Gozinta and Gozouta is nearly three years old, yet most of what I have to say in it still applies in the current day.

What has changed in the past three years is that HQMF is now in its second release cycle, and there are significant initiatives using it, including the Measure Authoring Tool, and Query Health. There are yet more opportunities to use it to define not just how a quality measure is computed, but also to define the inputs (and possibly even outputs) of a clinical decision support process. Just being able to describe the inputs to a CDS process in a way that would allow Health IT systems to automatically generate an appropriate interface to a CDS implementation would be a tremendous game changer.

This should be a consideration of the ONC S&I Framework Health eDecisions project. I have some ballot comments on HQMF Release 2.0 that HL7 will soon be publishing that will enable this kind of use, based on some earlier standards work that IHE did. That never got adopted, I think in part because a standard like HQMF was missing from the protocol. There is emerging work in the CDS space from the Clinical Decision Support Consortium (an active participant in the Health eDecisions project) that could readily take advantage of synergies between it, and HQMF as a description of the inputs it is expecting. The CDSC work takes a CCD document from an EHR and develops from it, a list of needed interventions for a patient, which it returns to the sending EHR.

The Data Criteria section of HQMF owes its existence in part to some of that early IHE work on Care Management. The idea was that the “data of interest” to the system (in the case of HQMF, data of interest to the measure) needs to be well defined. And having defined it well, and in a computer readable format, it could be used to automatically generate an input for a clinical decision support system. That input could be a CDA Document, implemented using the CCD specification, or one of the documents specified in the CCDA specifications. It need not contain all of the specified data of interest, just that data of interest that is available to the provider, in order to be useful.

Knowing what data is of interest can also be used on the EHR side to prompt the provider to ask good questions. This is yet another form of Clinical Decision Support.

One of the missing points will be trying to figure out how to specify what the outputs of the Clinical Decision Support system would look like. Here, I believe we need to do more work on care planning. The output of the CDS system can be a care plan that specifies further diagnostics, interventions or goals which might be appropriate for the patient. Specifying what the outputs look like in a way that is actionable is important. But it need not be so detailed as to suggest exactly what needs to take place and in what order, as that is a case where systems might innovate.

  -- Keith

Gozinta and Gozouta meets Query Health to revolutionize CDS

I spent this morning in the S&I Framework project leads meeting.  This afternoon I walked across the hall to another S&I Framework project that was having a meeting at the same time, skipping most of the introductory material at the kick-off session (although I did stay long enough to tweet one of Farzad's statements completely out of context).

Across the hall, several ONC funded Clinical Decision support project teams were meeting to discuss what was needed to standardize CDS for the 2016 Standards and Certification Criteria (which as Doug Fridsma reminds us, is really only 18 months away).  There was quite a bit of back and forth at this session, led by Jacob Reider, and I certainly stirred up the pot in the afternoon session.  But then again, I think they know what they were getting when I walked into the room.

Jacob had a great slide he was dynamically updating during the presentation that identified the various components of clinical decision support for which standards would need to be selected.  Surrounding the various boxes in which the components were listed was a box which described the scope of this particular ONC (and soon to be S&I) effort with respect to standards.  That box shrank and grew (and shrank again) as the discussion went on.

Blackford Middleton described five different kinds of CDS Interventions:

• Alerts
  Think of this as the typical black-box or question/answer approach that most people not really familiar with CDS go to first.  An alert is a notification that something is needed, not needed, appropriate, inappropriate, et cetera, based on some set of clinical data.  It need not be a pop-up (in fact, shouldn't be in most cases).
• Order Sets
  A way to represent common things that need to be done under particular circumstances.
• Info Buttons
  Places where someone can ask for more information about a particular data item (or set of data items)  being accessed.
• Data Display
A way to represent information that provides value (e.g., overlaying a plot of weight vs. Blood pressure)
• Documents
  "Smart forms" is how Blackford describes this.  Templates appropriate to a particular type of encounter or activity is a way that I might describe this.

In my thinking, the first three items are where we should focus our attention for Stage 3/2016 Standards and Certification Criteria.  There's a lot more work done on these three than on the latter two, and given that we have only 18 months, we need to bite off a useful and meaningful chunk (pun intended), without trying to solve every last CDS problem there is.  After all, anything left over we can address in stage 4 (only half joking here -- there's enough talk about stage 4 in policy circles that it could happen).

A lot of input to the discussions happened in the morning, and I missed most of it.  Thankfully, I might add.  In part, it was because most of what they discussed fell "above the line" on Jacob's chart (outside of scope).  The chunk above the line talked about standards important to implement a modular, standards-based clinical decision support service, but did not standards that would be used to integrated that with an EHR.

My thoughts on this are very strong:  I really don't care what language you use to represent knowledge, or how you implement your clinical decision support rules.  What I want to know are three (or maybe four) things:

• At what points the CDS intervention wants to be triggered,
• What the gozinta's are (what data it wants to see),
• What the gozouta's are (how do I interpret what it sends back),
• What the (XML) format is for communicating items 2 and 3 above.

Gozinta and Gozouta refers to a previous post I made about process improvement and building measurement into a process, and its intricately tied into my thinking in this space.  If you can tell me in a machine readable way (and NO, I do not mean an Excel spreadsheet), what data elements you are interested in, and how to represent that, then I can automate the outbound interface to the CDS service.

If you can tell me when to trigger it, then I can generate the message at the appropriate time.  Finally, if you can tell me the list of different kinds of responses (proposals for or against this screening, diagnostic test, diagnoses, treatment, or suggested care, ask these additional questions), how they are to be interpreted, and the format in which they are represented, then I can provide appropriate feedback in an EHR.

One of the cooler things that HL7 implemented in the HQMF standard was the data criteria section.  As currently being implemented in the Query Health project, this section identifies just the data elements of interest for a query.  In this context, it is a machine readable representation of a list of those data elements that could either be returned by the query, or used to identify specific items of interest.

In Query Health, we have a way to represent a description of problems, medications, allergies, encounters, procedures, demographics, et cetera, where we can specify the data element, and the specific code or value set, or range of relevant values associated with it.  It is only those elements that are later used to evaluate the query.

I strongly recommended the content of the HQMF DataCriteria section to this CDS workgroup as being the way to represent the information requested in an exchange.  In fact, I've even asked for the CCD requirements for the Partners CDS service that they are developing so that I can show them how to represent those requirements in a machine readable, unambiguous fashion.

I would also strongly recommend coordination with the other ONC S&I Framework efforts, including the Clinical Element Data Dictionary (CEDD or is it HDD now?) efforts coming out of Transitions of Care, Query Health and other workgroups.

Finally, just as IHE applied CCD templates to HL7 Version 3 messages, I would apply the Consolidated CDA templates to those data elements in a VMR implementation (presently a UML model in HL7) that used the HL7 Care Record messages as a concrete representation for exchange (now being reballoted as a standard).

On the gozouta side, I need to dig up the past work IHE did on Request for Clinical Guidance.  Essentially what we did is describe how you would make suggestions in the Care Plan.  So gozinta is essentially a message representation of the machine readable data in a Consolidated CDA document, gozouta is the same thing back, with suggested additions in the Care Plan (e.g., as suggested options for screening, treatment or diagnosis).

This could readily address both "Alerts" and "Order Sets", as the care plan could describe "alert" type responses, or suggested things that could be ordered.  It simply depends on how the EHR expects to use those things as to whether the CDS intervention becomes an "Alert", or an "Order Set", as described in Blackford's classification above.

In the InfoButton space, IHE is already working on a profile.  Join up, let's not duplicate effort.

This meeting was quite an interesting diversion for me.  I might have to find a way to get to AMIA this year, just so I can be a fly in the ointment again.

-- Keith

P.S.  Reminder to self: Finish reading Jerry's book on CDS and write a review.

---

I assigned myself an experiment after while the first part of this post this afternoon.  How would I use the data criteria section of HQMF to represent a data set used for Clinical Decision Support.  While I had asked someone to supply me with a set of data elements, and was going to follow up on this post, I realized about two hours ago (it's Oh-dark-thirty or so now) that it just so happens that I have a ready made list of data elements already created in this post (on what the summary care record should be for Meaningful Use Stage 2).

Here's the list of data elements:
(b) Standards When supplied in an electronic form, the summary care record shall be formatted according to the standards specified in §170.205(a)(3).
(1) Race and ethnicity. The standard specified in § 170.207(f)
(2) Preferred language. The standard specified in § 170.207(j)
(3) Smoking status. The standard specified in § 170.207(l)
(4) Problems. At a minimum, the version of the standard specified in § 170.207(a)(3)
(5) Encounter diagnoses. The standard specified in § 170.207(m)
(6) Medications. At a minimum, the version of the standard specified in § 170.207(h); and
(7) Reserved (For Allergies)
(8) Procedures. The standard specified in § 170.207(b)(2) or § 170.207(b)(3)
(9) Immunizations. The standard specified in § 170.207(i)
(9) Laboratory test(s). At a minimum, the version of the standard specified in § 170.207(g)

Now, let's represent that list in a data criteria section.  This first chunk defines model elements which will be referenced later.  These model elements are simply handles onto different kinds of data, such as demographics, problems, allergies, et cetera.  No matter what the Data Criteria, these definitions are the same and could readily be replaced by one line of XML directing you to a publicly available resource that could be "inserted" at that point using <xi:include>.


<dataCriteriaSection 
  xmlns="urn:hl7-org:v3"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:type="POQM_MT000001UV.DataCriteriaSection"
  >
  <code codeSystem="2.16.840.1.113883.6.1" code="57025-9"/>
  <title>Data Criteria Section</title>
  <text>This section describes the data criteria.</text>
  <definition>
    <observationDefinition>
      <id extension="Demographics"
        root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <encounterDefinition>
      <id extension="Encounters" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </encounterDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Problems" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>

  <definition>
    <observationDefinition>
      <id extension="SocialHistory" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>

  <definition>
    <observationDefinition>
      <id extension="Allergies" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <procedureDefinition>
      <id extension="Procedures" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </procedureDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <observationDefinition>
      <id extension="Vitals" root="2.16.840.1.113883.3.1619.5148.1"/>
    </observationDefinition>
  </definition>
  <definition>
    <substanceAdministrationDefinition>
      <id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </substanceAdministrationDefinition>
  </definition>
  <definition>
    <substanceAdministrationDefinition>
      <id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
      />
    </substanceAdministrationDefinition>
  </definition>
  <definition>
    <supplyDefinition>
      <id extension="RX" root="2.16.840.1.113883.3.1619.5148.1"/>
    </supplyDefinition>
  </definition>


OK, so now we have some demographics that we are interested in.  I show how we'd specify that we are interested in the race, ethnicity, and preferred language of the patient, which are listed in my data set of things I need to know in order to perform some kind of CDS.  Arguably, preferred language is not useful in this context, but age or gender might be.  Take it as a given that I have SNOMED CT codes that allow you to specify those as well.


  <entry>
    <localVariableName>Race</localVariableName>
    <observationCriteria>
      <id extension="Race"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Race"
        codeSystem="2.16.840.1.113883.6.96" code="103579009"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
  <entry>
    <localVariableName>Ethnicity</localVariableName>
    <observationCriteria>
      <id extension="Ethnicity"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Ethnic Group"
        codeSystem="2.16.840.1.113883.6.96" code="364699009"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.6'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
  <entry>
    <localVariableName>PreferredLanguage</localVariableName>
    <observationCriteria>
      <id extension="PreferredLanguage"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="Language Finding"
        codeSystem="2.16.840.1.113883.6.96" code="106133000"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.10'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Demographics"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>

This next criterion says that I'm interested in smoking status, and that  it comes from the Social History part of the model.

  <entry>
    <localVariableName>SmokingStatus</localVariableName>
    <observationCriteria>
      <id extension="SmokingStatus"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code displayName="tobacco smoking behavior - finding"
        codeSystem="2.16.840.1.113883.6.96" code="365981007"/>
      <value xsi:type="CD" valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.12'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="SocialHistory"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>



This next criterion says that I'm interested in problems, and that  it comes from the Problems part of the model.


  <entry>
    <localVariableName>Problems</localVariableName>
    <observationCriteria>
      <id extension="Problems"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <value valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.1.3' xsi:type="CD"/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Problems"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>


I'll handle medications and immunizations together.  The next part says that I'm interested in these and that they come from the medications and immunizations part of the model.

  <entry>
    <localVariableName>Medications</localVariableName>
    <substanceAdministrationCriteria>
      <id extension="Medications"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
      <participant typeCode="CSM">
        <roleParticipant classCode="THER">
          <code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.8"/>
        </roleParticipant>
      </participant>
      <definition>
        <substanceAdministrationReference moodCode="DEF">
          <id extension="Medications" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </substanceAdministrationReference>
      </definition>
    </substanceAdministrationCriteria>
  </entry>
  <entry>
    <localVariableName>Immunizations</localVariableName>
    <substanceAdministrationCriteria>
      <id extension="Immunizations"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226984"/>
      <participant typeCode="CSM">
        <roleParticipant classCode="THER">
          <code valueSet="2.16.840.1.113883.3.1619.5148.11.45.170.314.207.9"/>
        </roleParticipant>
      </participant>
      <definition>
        <substanceAdministrationReference moodCode="DEF">
          <id extension="Immunizations" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </substanceAdministrationReference>
      </definition>
    </substanceAdministrationCriteria>
  </entry>

Now procedures: 

  <entry>
    <localVariableName>Procedures</localVariableName>
    <procedureCriteria>
      <id extension="Procedures"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226985"/>
      <code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.2'/>
      <definition>
        <procedureReference moodCode="DEF">
          <id extension="Procedures"
            root="2.16.840.1.113883.3.1619.5148.1"/>
        </procedureReference>
      </definition>
    </procedureCriteria>
  </entry>


And labs:



  <entry>
    <localVariableName>LabResults</localVariableName>
    <observationCriteria>
      <id extension="LabResults"
        root="2.16.840.1.113883.3.1619.5148.3.20120214.165226983"/>
      <code valueSet='2.16.840.1.113883.3.1619.5148.11.45.170.314.207.7'/>
      <definition>
        <observationReference moodCode="DEF">
          <id extension="Results" root="2.16.840.1.113883.3.1619.5148.1"
          />
        </observationReference>
      </definition>
    </observationCriteria>
  </entry>
</dataCriteriaSection>


This XML took me all of 15 minutes to craft (the remaining time has been spend writing the rest of this post).  One of the reasons it went so fast is that there's a lot of repetition in this content, given the breadth of what stage 2 asks for in a summary record. So, while it's clear than for this data set you could simplify the XML, you may want the expressive power that I didn't show in this example for other CDS use cases (e.g., to limit the data element to the first/last of a series of identical measures, or within a given date range, et cetera).

Long time readers probably get it that I've already shown these data criteria as being sufficient to execute queries against a patient population in query health to compute counts of patients matching the measure criteria (another section of HQMF).  Given a population of ONE patient this data criteria identifies the clinical data that a CDS system needs to compute with, and can be used by the EHR to locate it.

Once we've located the data, it's (as a former colleague liked to say), a simple matter of code to turn it into an XML message in some format.  For CDS, I happen to like the HL7 Version 3 Care Provision message.  In the HL7 V3 world these are almost equivalent to CDA documents (and I've even got a specification for how to transform from one to the other and back), except that they usually contain no narrative.  So now I have a standard message format, a way to dynamically tell a system how to determine what goes in it, and from there, how to populate the content in the message.

What I've just described is a way, given a list of standardized data elements, to automate interface generation to a specialized CDS system, because it tells me (in that list of data criteria), how the interface should look.

What should I get back?

Well, I'd really like to see some proposals for screening, further diagnostics, new diagnoses, treatment that might be suggested, and references to the evidence supporting any of those.  I use the term proposal quite advisedly.  CDS systems propose, and depending on the implementation, either a provider or the systems decides what to do with this proposals.  Proposal is a special mood in HL7 Version 3.  Identifying something as a proposal is as easy as setting moodCode='PRP' on the acts returned by the CDS system.  So, anything that shows up as PRP on output is what the CDS system proposes for the patient in response to the given data inputs.

There is something else that's pretty interesting that could be done.  You could take the data in that message format, and the type of encounter, pick the appropriate document type from the CDA Consolidation guide, and populate it.

Oh my.

Idioms as insight into Models - A synthesis across Templates and CDS models

Software developers use programming languages in idiomatic ways all the time.  The infamous "endless" loop in C/C++ looks like this:

for(;;)
{
}

Most programmers will learn to recognize these common idioms and move on.  Sometimes the idiomatic use so simple that it never needs to be codified, and is easily understood (like the endless loop above).  At other times, the idiom is rather complicated and in some ways, inexplicable.

Here is an example from XSLT.  See if you can figure out what it does before I explain it:

substring-before(concat(translate(X,'+','-'),'-'),'-')

This particular idiom is one I use regularly.  For a string X, it first translates any occurrence of '+' into a '-'.  Then it appends a '-' to the string.  Then it extracts whatever string appears before the '-' character. If X is an ISO 8601 formatted date-timestamp with an optional time zone, this expression will extract just the date-timestamp portion of it without the timezone.

Language developers will often take common idioms and use them to develop new language features that re-implement the idiomatic usage.  If I were writing an XSLT library, I'd certainly put in some timestamp manipulation functions to avoid having to write this in its idiomatic (and idiotic) form.

Idioms are important because they identify common patterns of use.  In looking over a number of templates in IHE, HL7 and HITSP, and identified a bakers dozen of common idioms.  From that, and a review of the documentation, we have enough information to put together a template meta-model.

Earlier today I was on a call talking about clinical decision support and GELLO.  GELLO has to be my least favorite language for expressing things in a clear form. It shares a common feature with XSLT which is that it is declarative.  Declarative programming is counter-intuitive for most people when the first encounter it.  SQL is also a declarative programming language.  The benefit of declarative programming languages is that they specify what the result looks like, not how to generate it, or the order of the steps needed to accomplish the task.  The counter-intuitive part is that you have to think "backwards" and "upside-down" or "inside-out" and forget procedures.  It takes a while to learn that skill (or at least it did for me).

One of the pieces of feedback that the speaker had gotten about GELLO was the love/hate, and mostly hate relationship that non-technical people had with GELLO when examining clinical decision support rules.  I feel almost the same way about OCL as I do about GELLO, which isn't surprising since GELLO is derived from OCL (and should become a proper subset of it some day).

Having recently had a similar experience with OCL (because MDHT expresses constraints in OCL), and having figured out that the idioms used are a key to figuring out the meta-model, what I realized was that the same was also true in Clinical Decision Support.  The idioms used in clinical decision support are what will be important to providers when we finally figure out what it's meta-model is.  For Templates, we had to get to over a hundred of them before I could see (and use) common idioms.  Having over 1000, I'm pretty certain we have all the key ones nailed down.  I suspect we'll need to do the same for Clinical Decision Support.

There's still some odd-ball stuff that we'd have to represent directly for templates in a "low-level" construct like Schematron/XPath or OCL.  We can live with that.  After all, sometimes you need to call into an assembly language routine from a high level language too.  I'm certain the same will be true for clinical decision support as well.

As I think about this even more, I'm struck by yet another similarity.  High level languages (and from them Object-oriented languages) originated from assembly.  If you think of GELLO or Schematron as the assembly language, you can see where models and high level languages for templates (or CDS) will finally emerge.

I love it when separate activities come together like this.

Leveraging Standards for ACO Development

One of the things I didn't get to do at HIMSS was connect up with someone who wanted a brain dump from me on leveraging healthcare standards to support Accountable Care Organizations.  One of my recent tweeps asked if EHR was required to support ACOs, and another responded that EHR is not, but that an HIE is.  To add to the alphabet soup, I'd like to throw in CDS.

What I'm hearing about most often from Accountable Care Organizations is that they are focused on cases where they can quickly realize savings.  The low hanging fruit seems to be in the area of chronic disease management, care planning and follow-up.

The top chronic diseases appear to be Diabetes [all seem to agree this is a top priority], Chronic Obstructive Pulmonary Disease (COPD), Congenstive Heart Failure (CHF) [these next two are very common], Coronary Arterty Disease (CAD), and Hypertension.

Other areas of attention are on care-planning and follow-up for post-surgical and post-ED visits.

From a standards perspective, the key areas of focus is on sharing data from various settings where the ACO has access to it.  The standard that most are already adopting is the HITSP C32/HL7 Continuity of Care Docuement as it is already contained within the Meaningful Use Regulation.  Another area of attention is on accessing laboratory results.

From a vocabulary perspective:
While many are still using ICD-9-CM codes for diagnoses, some are pushing for SNOMED CT codes.  For medications, the push it towards RxNORM, and for labs to LOINC.

So far, motherhood and apple-pie, and consistent with national directions.

Where their seems to be some struggle is on data elements needed for managing care for each of these cases.  I expect there there are still quite a number of spreadsheets being tossed around.

The next step for standardization in this area would be to apply codes to the various guidelines for treating these diseases.  The hard part is deciding on which guidelines to apply for care.  The easy part is selecting the codes for the important components.  Let's take an example of what I mean, by looking at the International Diabetes Federation's Global Guideline for Type 2 Diabetes.  I picked this guideline arbitrarily, you could use any other guideline for this effort.

Having chosen the guideline, let's take a couple of its recommendations and apply codes to them:
Guideline SD2 (see Page 9 of the PDF above) recommends a fasting oral glucose tollerance test for screening.  So, now we need to code the tests.  Out comes RELMA and we find that the most common test in LOINC^® is: 1504-0 Glucose^1H post 50 g glucose PO mg/dL.  There are some 92 other result codes that we could also look for, but I won't bother listing them.

Guideline SD4 (same page) references the WHO criteria for diagnosis of Diabetes (peeling the onion as it were).  So, now I dig out my CliniClue Browser and look up the code for Diabetes Melitus (73211009 in SNOMED CT^®).  Since I'm interested at this point in all subtypes of Diabetes underneath that code, I'll deal with that as an Intentional value set.

If we wanted to address other means of screening (e.g., Urine dipstick testing), I could look up the codes for those in RELMA as well.

I'll skip the Care Delivery section and move on to the Education section since Care Delivery references content in the other sections.

Guideline ED1 talks about Diabetes Type 2, so again I find the right SNOMED CT code (44054006).

Guideline LS2 talks about a type of care provider: dieticians.  I can dig up SNOMED codes for that, or use the Healthcare Provider Taxonomy codes (a Registered Dietician is 133V00000X in that coding system).

Guideline TT1 talks about HbA1c levels, so I need LOINC codes for that.  I find two codes in LOINC using RELMA (both of which are common):

• 17856-6 Hemoglobin A1c/Hemoglobin.total % Hgb
• 4548-4 Hemoglobin A1c/Hemoglobin.total % Hgb

Diabetes can cause retinopathy, so there are guidelines around eye screening.

Guideline ES1 talks about Eye Examinations, so I can find CPT codes for that (but not display them...)

It also discusses retinopathy, so I can find SNOMED CT codes for that (399625000) and explicitely for Diabetic Retinopathy (4855003).

 

And so on and so forth until I've got codes for the entire guideline.  Picking the guideline, is, as I said, the hard part.  Coding the stuff is Clinical Informatics drudgery, and can be quickly done (I did a good bit of the IDF guide in about 6 hours).  Some of these codes will be for conditions, others for providers, encounter types, lab results and orders, vital signs, services, medications, et cetera.

 

If I'm smart, for each of these things I've got a code for, I should also have a link back to at least one (if not all) requirements for that thing in the guideline.  This can be used later!

 

The list of coded stuff tells me what I want to see in lab reports, CDA documents, and more.  Having that list makes the job much easier, because now I can make sure that information is captured in the EHR, coded in a CDA document, or imported from laboratory reports (and mapped to LOINC where needed).

 

All those linked references I talked about earlier can also be used in Infobuttons in the EHR, or in patient educational content.

 

IHE developed the Care Management (CM) (pdf) profile to support chronic disease management.  Uptake has been slow, but I'm starting to get feedback on it, and at least one organization has implemented it that I know about.  It's designed around exactly this sort of process, and the beauty of that profile, if it were implemented fully, is the automatic generation of interfaces (no more interface engineering -- imagine taking that cost out of healthcare).

 

The next big challenge for ACOs is applying clinical decision support to this information.  The guidelines supply the rules that should be invoked on the data that we've coded, and those can be written in whatever form (programming language, rules engine, et cetera) needed.  Thomson Reuters is working on an AHRQ grant to develop electronic Recommendations.  This is essentially the step before coding a guideline into Clinical decision support logic.  A necessary step prior to describing the logic is what I just described, coding the guideline.

 

Both the CM profile and the IHE Request for Clinical Guidance (RCG) (pdf) profile support mechanisms to integrate clinical decision support as a service.  The RCG profile includes an appendix to show how to map back and forth from a CDA document to a Care provision message to support the integration of CDS as a service.    The Clinical Decision Support Collaborative is currently investigating how to integrate CDS services with ERHs, and these profiles provide some support and a standards based interface that group could take advantage of.

 

CDS is the next big area where standardized interfaces are needed.  IHE was just a bit early in its development of profiles on CDS, as the current market is focused on Meaningful Use Stage 1.  But stage 2 and stage 3 are coming, and CDS will play a key role in those stages.

I'd love to see some national efforts around the selection of and coding of guidelines for chronic conditions that could be widely shared.  I think that effort would give ACOs a huge head start.  Most often, it's not the codes that change in the decision logic, but the various measure parameters (should HbA1c be managed to 6 or 7%), should medication X be applied at this point or that.  Coding national guidelines in this way would let ACOs get a head start, and if they wanted to adjust the decision logic because they have a better idea of how to manage the condition, more power to them.  At least they could skip the step of finding the codes.  It pains me to understand how much clinical informatics expertise we are wasting doing the same work repeatedly (in some cases, reinventing guidelines that others have already well established).

Oh, and this would be a process that would have quality measurement built in.