Thursday, April 26, 2012
Because We Can
I've been having and reading discussions about standardizing Advance Directives with a number of different groups. There is a suggestion out there that it is time to create a standard format for conveying information about an Advance Directive, perhaps using CDA. Others, coming from the US HIT Standards Committee Power Team seem to suggest that current mechanisms for recording Advance Directives in the Consolidated CDA need to be extended (see page 7).
The point made in the latter document is that it isn't enough to know that one exists, but that one must also know where to get it and how to access it easily, that it should (in stage 2) have information about CPR and Intubation, and in stage 3, it contain more detailed information and support versioning.
I don't support an effort to standardize the format of Advance Directives at this time. While standardizing the information is necessary, the US policy environment is such that much more is needed before that can even be useful. I'd rather not expend effort on it from a pool of limited resources without first ensuring that the end result will be useful.
One of the suggestions is that the document record information about whether a patient should be intubated or resuscitated. This is challenged by the fact that orders for DNR and/or Intubation are Physician written orders, and have different standings in different states. They may also be conditional based on a particular hospital stay or procedure, may be time limited, et cetera. The first step, before "standardizing" such information would be to first understand the policy environment, and to make sure that all policy variations that need to be encoded are understood. We don't yet have that information readily available in the US, and until we do, deciding how to "standardize" the format is kind of beside the point. We can tell you how to transmit the information, but we cannot tell you how to interpret it. How useful is that?
Some work has been done by Aging with Dignity to develop a "standard form", known as Five Wishes. Even that widely accessible and broadly funded activity has run into policy challenges in developing a form that could be readily used in all 50 states of this country (right now, it only works by itself in 42 states, 8 others require "workarounds").
The next challenge is deep. An advance directive can be subsequently overridden by a later version (as noted in the first link). How would you ensure that you had the latest version? To do so would require policy with regard to registration of such documents, combined with a technical infrastructure to support it.
Don't get me wrong. I believe that it will be useful at some point to support standardizing the format of an advance directive, but there are certainly bigger fish to fry right now. I'd rather see the limited resources we have applied to more critical issues. We need more than "because we can do it" as a reason to create a standard. The environment has to be right as well. If the standard exists, but nobody can use it because the policy environment won't support it, we're just wasting time.
The point made in the latter document is that it isn't enough to know that one exists, but that one must also know where to get it and how to access it easily, that it should (in stage 2) have information about CPR and Intubation, and in stage 3, it contain more detailed information and support versioning.
I don't support an effort to standardize the format of Advance Directives at this time. While standardizing the information is necessary, the US policy environment is such that much more is needed before that can even be useful. I'd rather not expend effort on it from a pool of limited resources without first ensuring that the end result will be useful.
One of the suggestions is that the document record information about whether a patient should be intubated or resuscitated. This is challenged by the fact that orders for DNR and/or Intubation are Physician written orders, and have different standings in different states. They may also be conditional based on a particular hospital stay or procedure, may be time limited, et cetera. The first step, before "standardizing" such information would be to first understand the policy environment, and to make sure that all policy variations that need to be encoded are understood. We don't yet have that information readily available in the US, and until we do, deciding how to "standardize" the format is kind of beside the point. We can tell you how to transmit the information, but we cannot tell you how to interpret it. How useful is that?
Some work has been done by Aging with Dignity to develop a "standard form", known as Five Wishes. Even that widely accessible and broadly funded activity has run into policy challenges in developing a form that could be readily used in all 50 states of this country (right now, it only works by itself in 42 states, 8 others require "workarounds").
The next challenge is deep. An advance directive can be subsequently overridden by a later version (as noted in the first link). How would you ensure that you had the latest version? To do so would require policy with regard to registration of such documents, combined with a technical infrastructure to support it.
Don't get me wrong. I believe that it will be useful at some point to support standardizing the format of an advance directive, but there are certainly bigger fish to fry right now. I'd rather see the limited resources we have applied to more critical issues. We need more than "because we can do it" as a reason to create a standard. The environment has to be right as well. If the standard exists, but nobody can use it because the policy environment won't support it, we're just wasting time.
Wednesday, April 25, 2012
Footballs, Star Wars, and Dr. Doolittle
What do Footballs, Star Wars, and Dr. Doolittle have in common? While normally unrelated, they come together in a post from Dirk Stanley over at his Free CMIO Perspecive blog.
Dirk starts out with a discussion of Push and Pull (remember the push-me-pull-you from Dr. Doolittle). He notes that the lack of a national patient identifier prevents adequate use of pull. However, push and pull are two sides of the same animal. Even with a national patient identifier, it is still necessary to send enough patient demographics to ensure patient identity when communicating, regardless of whether you are pushing or pulling. And while NwHIN Direct is dealing with the push side, NwHIN Exchange includes specifications for push and pull (see Query for Documents).
The remainder of his discussion is one what one would pull, which he describes as a football. Dirk suggests that a single summary format be provided for all to use.
There's been some efforts from a few professional societies to move towards a single medical summary format. In fact, most of the documents providers use contain quite similar information: Problems, Medications and Allergies top the list and are present in just about all of them. I spent a good bit of time harmonizing the various definitions of the Summary of Care Record specified in the Meaningful Use Stage 2 rules.
Dirk describes his Hand-off note, which he calls the "Football".
It contains:
The simplicity of most of his section titles (with the exception of PMhx/PSurgHX) is appealing , especially from a patient perspective. All of this content is already available in the CCR and CCD and can also be included in any Consolidated CDA document (in other words, "been there, done that"). In fact, those documents include more detail.
So, what other stuff is missing?
Those would make for a more interesting and complete football, but we are still back to what CCR and CCD already provided.
Clinical documentation serves several purposes. It provides a legal and medical record of what was done during an encounter. It communicates to other providers, or acts a reminder to the same provider in the future. It acts as evidence that appropriate procedures were followed (e.g., for accreditation or billing purposes). Healthcare providers in different settings need to record different information because the documentation serves these different purposes.
I think Dirk's idea that we can create a summary document that serves one purpose is laudible, but, I'm also certain that providers will never agree to adopt any one particular format that doesn't address their workflows.
At one point in time I knew of a site where two providers each had their own documentation format for what they did in a visit, duplicated with slight variations to deal with different state rules. Neither would agree to use the other's format, nor did they desire to consolidate that two different state variants, even though the documented the same things even in the same order. Unbeknownst to them, it was possible to encode the headings they used identically to a particular vocabulary (LOINC), and that is what the software I was deploying at the time did. So as far as the software was concerned, the data was similarly encoded and could be compared in meaningful ways in the application, even though the providers saw it differently. This becomes very important.
Healthcare providers are very jealous of their processes. I'm not sure I'd go so far as to introduce a new process, or a new document format to them. Instead, I'd develop a better way to classify the information they already provide. LOINC provides a great list of codes for document sections, but doesn't connect it well into an ontology. Consider the following different ways that one can represent a reason for care:
Each of these is used in different contexts, and some contexts even use several of the above. Yet I see little in medical ontology that describe these different data points as describing reasons for care. I don't see a need to harmonize the different contexts to say "Reason for Care", but I do see a great deal of utility in developing an ontology that links these different kinds of "reasons for care" to a single code so that systems can reason across these contexts.
While Dirk asserts that we need a new document to harmonize care, I think a better way to handle the challenge would be to codify and relate the contextual knowledge across the different kinds of clinical documents. That way, we could enhance existing processes and workflows, rather than replacing them.
Dirk starts out with a discussion of Push and Pull (remember the push-me-pull-you from Dr. Doolittle). He notes that the lack of a national patient identifier prevents adequate use of pull. However, push and pull are two sides of the same animal. Even with a national patient identifier, it is still necessary to send enough patient demographics to ensure patient identity when communicating, regardless of whether you are pushing or pulling. And while NwHIN Direct is dealing with the push side, NwHIN Exchange includes specifications for push and pull (see Query for Documents).
The remainder of his discussion is one what one would pull, which he describes as a football. Dirk suggests that a single summary format be provided for all to use.
There's been some efforts from a few professional societies to move towards a single medical summary format. In fact, most of the documents providers use contain quite similar information: Problems, Medications and Allergies top the list and are present in just about all of them. I spent a good bit of time harmonizing the various definitions of the Summary of Care Record specified in the Meaningful Use Stage 2 rules.
Dirk describes his Hand-off note, which he calls the "Football".
It contains:
- Patient Name and DOB
- Emergency Contact Information
- Code Status
- Handoff Date
- Handoff From
- Expected Handoff To
- Author (who is pushing the football today)
- Co-authors (who pushed the football in the past)
- Allergies
- PMhx/PSurgHX (History including Problems and Surgeries)
- Significant Studies
- What I Did
- Active Medications (at time of Handoff)
- To Do List
The simplicity of most of his section titles (with the exception of PMhx/PSurgHX) is appealing , especially from a patient perspective. All of this content is already available in the CCR and CCD and can also be included in any Consolidated CDA document (in other words, "been there, done that"). In fact, those documents include more detail.
So, what other stuff is missing?
- What about family and social history? Patients keep getting asked for it, why not provide a record of what each provider knew?
- What about vaccination history? This is important for ongoing health maintenance.
- What about a section on "What I decided or recommended?" to show the clinical judgments made during the encounter?
- What about a section on "What I discovered?" that describes what information went into decisions or recommendations (e.g., significant physical examination findings).
Those would make for a more interesting and complete football, but we are still back to what CCR and CCD already provided.
Clinical documentation serves several purposes. It provides a legal and medical record of what was done during an encounter. It communicates to other providers, or acts a reminder to the same provider in the future. It acts as evidence that appropriate procedures were followed (e.g., for accreditation or billing purposes). Healthcare providers in different settings need to record different information because the documentation serves these different purposes.
I think Dirk's idea that we can create a summary document that serves one purpose is laudible, but, I'm also certain that providers will never agree to adopt any one particular format that doesn't address their workflows.
At one point in time I knew of a site where two providers each had their own documentation format for what they did in a visit, duplicated with slight variations to deal with different state rules. Neither would agree to use the other's format, nor did they desire to consolidate that two different state variants, even though the documented the same things even in the same order. Unbeknownst to them, it was possible to encode the headings they used identically to a particular vocabulary (LOINC), and that is what the software I was deploying at the time did. So as far as the software was concerned, the data was similarly encoded and could be compared in meaningful ways in the application, even though the providers saw it differently. This becomes very important.
Healthcare providers are very jealous of their processes. I'm not sure I'd go so far as to introduce a new process, or a new document format to them. Instead, I'd develop a better way to classify the information they already provide. LOINC provides a great list of codes for document sections, but doesn't connect it well into an ontology. Consider the following different ways that one can represent a reason for care:
- Admission Diagnosis
- Reason for Visit
- Chief Complaint
- Reason for Referral
- Pre-operative Diagnosis
- Pre-procedure Diagnosis
Each of these is used in different contexts, and some contexts even use several of the above. Yet I see little in medical ontology that describe these different data points as describing reasons for care. I don't see a need to harmonize the different contexts to say "Reason for Care", but I do see a great deal of utility in developing an ontology that links these different kinds of "reasons for care" to a single code so that systems can reason across these contexts.
While Dirk asserts that we need a new document to harmonize care, I think a better way to handle the challenge would be to codify and relate the contextual knowledge across the different kinds of clinical documents. That way, we could enhance existing processes and workflows, rather than replacing them.
Tuesday, April 24, 2012
Harmonizing Value Sets in MeaningfulUse Stage2
Recently in discussions about Meaningful Use Stage 2 Certification criteria and in subsequent discussions on quality measures, someone pointed out inconsistencies in value sets used for smoking and/or tobacco use. The other day, I posted a list that Cecil Lynch had provided that maps the Meaningful Use terms to SNOMED CT codes.
I took a look at quality measures that CMS proposes for 2014. I didn't see any references to tobacco or smoking in the Hospital measures, but two measures do reference tobacco or smoking in the EP measures:
One measure: NQF 28, clarifies that screening for tobacco use includes "any kind of tobacco".
Another measure on Preventive Care and Screening from Quality Insights of Pennsylvania/Centers for Medicare & Medicaid Service explicitly references cigarette smoking only in one of the denominators:
The real point here is that these and many other terms need to be harmonized across Meaningful Use and the proposed quality measures. This problem is not isolated to smoking status, it has been reported to be present in a variety of other quality measures.
My hope is that current efforts towards development of a publicly accessible value set registry will go a long way towards making this possible. But until that is done, and CQM developers take advantage of it, we'll continue to be asked to record one thing, and compute on something else.
I took a look at quality measures that CMS proposes for 2014. I didn't see any references to tobacco or smoking in the Hospital measures, but two measures do reference tobacco or smoking in the EP measures:
One measure: NQF 28, clarifies that screening for tobacco use includes "any kind of tobacco".
Another measure on Preventive Care and Screening from Quality Insights of Pennsylvania/Centers for Medicare & Medicaid Service explicitly references cigarette smoking only in one of the denominators:
Denominator 2: All patients aged 20 through 79 years who have Multiple Risk Factors (2+) of the following: Cigarette Smoking, Hypertension, Low High Density Lipoprotein (HDL), Family History of Premature CHD, or Age (men ≥ 55; women ≥ 65)The challenge with either of these measures is that they cannot be computed from the Meaningful Use standard for smoking status:
(l) Smoking status. Standard. Smoking status types must include: Current every day smoker; current some day smoker; former smoker; never smoker; smoker, current status unknown; and unknown if ever smoked.Many clinicians have suggested that the vocabulary standard for smoking status be broadened to include any tobacco use. That still wouldn't solve the problems across these two measures. Other clinicians will point out that any kind of smoking should probably be included in the second measure I described.
The real point here is that these and many other terms need to be harmonized across Meaningful Use and the proposed quality measures. This problem is not isolated to smoking status, it has been reported to be present in a variety of other quality measures.
My hope is that current efforts towards development of a publicly accessible value set registry will go a long way towards making this possible. But until that is done, and CQM developers take advantage of it, we'll continue to be asked to record one thing, and compute on something else.
Friday, April 20, 2012
IHE Cardiology Technical Framework Supplement Published for Public Comment
A CDA Implementation Guide for Cardiac Catheterization reporting...
|
Forward Compatibility and the use of Templates with HL7 CDA
I had an interesting conversation with Wes Rishel this afternoon regarding his post on "Frozen Interface Syndrome" in which he talks about bilateral asynchronous cut-over. He brings up an excellent point, which is that there need to be principles in the development and revision of standards in which we enable compatibility at the same time as we allow for advancement, to avoid freezing interfaces.
There's a phrase used in standards development that talks about backwards compatibility. A standard is said to be backwards compatible when it enables all features of the previous version to be represented in the new version. This ensured that there would be a smooth transition from one version of the standard to the next because it ensures that functionality is maintained across versions. But it is insufficient to allow for bilateral asynchronous cut-over. To do that, we need to design for foward compatibility.
Templated CDA goes a step further because there are ways to develop standards that ensure that:
There's a phrase used in standards development that talks about backwards compatibility. A standard is said to be backwards compatible when it enables all features of the previous version to be represented in the new version. This ensured that there would be a smooth transition from one version of the standard to the next because it ensures that functionality is maintained across versions. But it is insufficient to allow for bilateral asynchronous cut-over. To do that, we need to design for foward compatibility.
Templated CDA goes a step further because there are ways to develop standards that ensure that:
- Systems expecting content formatted according to a new version of the standard can layer functionality to downgrade gracefully upon receipt of content formatted according to the old version.
- Systems expecting content formatted according to the old version of the standard can understand what to do upon receipt of content formatted according to the new version.
Each template identifier asserted by a component of a CDA document is immutable with respect to compatibility breaking changes, by agreement of HL7 Workgroups. I expect this principal will be formalized in the next version of the HL7 Templates standard. It is one that has been followed routinely for the past half-decade by HL7, IHE, HITSP, epSOS and other organizations developing templates for CDA and HL7 Version 3 messages.
This has some challenges, because if you make a compatibility breaking change in template X producing X.1, and template Y requires X, and template Z requires Y, then you must also change the identifiers of templates Y and Z to enforce the use of X.1 instead of X.
To give a concrete example, CCDA presently says that an Allergy template may contain a severity template. Let us suppose that healthcare has advanced to the point that we are ready to say that severity SHALL be provided with all allergies. At that point, we want to say that the Allergy section requires the new allergy template with the required severity, and so this becomes a "compatibility-breaking" requirement on the old section, and so must also be assigned a new identifier. And any document that wants to require that new section also breaks backward compatibilty, and so requires a new identifier.
But a system that understands the old allergy template should also be able to understand the new one. And it will also be able to understand the new section and the new document template. The problem is that it was never designed to know about these new templates. And so we must tell it that the content it receives also conforms to the older template structure. We would do that by asserting conformance to both the old and the new templates.
One would hope that we could take advantage of this notion of forward compatibility as much as possible in all future development of CDA templates, as it provides a mechanism to allow for bilateral asynchronous cutover that Wes and I would both find desirable. You'll note that these principles are already enabled via the incremental interoperability that HITSP and IHE used by layering new templates over existing HL7 templates providing varying degrees of interoperability.
I'll note that this mechanism does not address is the situation we are in today with regard to HITSP C32 Version 2.5 and its use of CCD 1.0, vs. the Consolidated CDA description of CCD 1.1. In that case, we can apply forwards compatibility in most, but not all cases. Due to limitations in existing care provision models at the time that CCD 1.0 was created, and their current state when CCD 1.1 was created, there are some templates that just aren't compatible between versions. There are transforms that can be applied to enable compatibility for many of the exception cases (I won't say all yet, because I haven't finished my analysis). I'll address how to do that when I get more time to focus on my Changing from HITSP C32 Version 2.5 to Consolidated CDA post.
In future versions of the Consolidated CDA guide, I expect similar situations to be quite rarely encountered, and so HL7 should be able to ensure forward compatibility in subsequent editions with little challenges.
On a final note, at the very least, when receiving a CDA, even one which an application doesn't know to interpret, every application should be able to display it. That provides at least a base level of interoperability between systems that should be present with just about every CDA implementation.
-- Keith
P.S. You'll note that I have yet to catch on to using the acronym CCDA for Consolidated CDA, but I recently noted that it does put the CCD back together with CDA, and so maybe I will adopt it. I just don't know how I feel about that yet. What do you think?
Thursday, April 19, 2012
When Clinical Documents are not Enough
One of the queries in ONC's 2014 Standards and Certification Criteria was on something that was originally described as a "Green Button" (see slide 13) in a list of ONC Proposed S&I Initiatives back in late 2010. Of course that button color has since been taken over by Smart Grid to enable customers to download their power consumption data, so they'd have to choose another color for it.
The request is under a section on Data Portability in the proposed rule.
The documents described in the Consolidated CDA guide are really designed to summarize the important outcomes of an encounter, or perhaps an episode of care. They were never designed to function as an EHR dump (nor was CCR for that matter). That doesn't mean some people haven't tried to use them that way. I've heard reports from one person on Twitter that he's aware of on EHR that dumps their entire patient history into a multi-megabyte CCD.
ONC does then attempt to address administrative data, in question 3. But they fail to account for operational data related to dynamic transactions (orders and payments), quality measurement, master file content, or user and access control information. One of the challenges in quality measurement today (and which is currently being looked at by both the HIT Standards and Policy Committees), is the disconnect between CQM data and EHR data. There are many questions of intent explicit in CQMs that aren't captured in the EHR, often because they are questions of clinical judgement, (e.g., medical appropriateness), In a system or workflow where the intent is to document what has been done (or in some cases not done), often what is not captured is why, and that is often the focus of exceptions in CQMs. So, the documents will have the what, but not often the why.
With regard to question 4, of course there are consequences that must be addressed and mitigations necessary. Whenever you add new functionality to a product, you need to perform a risk assessment. I would hope that should be obvious. I won't get into what those issues are because I'm not a security expert (although John Moehrke is).
In summary:
So much data goes into the configuration of an EHR, including test compendiums, medication formularies, order processing (including prescriptions), referral networks, data needed to conduct transactions, workflow configurations, clinical decision support configurations, documentation templates, et cetera. The patient's clinical data is but one component of the data needed.
The real challenge in transitioning is not exchanging clinical data that it manages, but rather, it is in configuring the EHR (which is more of a platform rather than an application) to match the processes of the healthcare provider, and to ensure that the data management supported by the EHR matches those processes.
Are there any other products where such a transition is possible? Can you just dump all of your SAP data and move it over to Oracle's CRM solution, or to Salesforce.com? (Unlikely) How about HR Management system? (Also unlikely) What about your business accounting data; could you just dump your info from one accounting system to another? (It depends on size of the organization and scale of the system -- for anything over small business size, not readily).
The request is under a section on Data Portability in the proposed rule.
We seek public comment on whether we should adopt a certification criterion that focuses on the portability of data stored within CEHRT. When a provider seeks to change EHR technology, we believe that they should have the ability to easily switch EHR technology—at a low cost—and migrate most or all of their data in structured form to another EHR technology. In the absence of this capability, providers may be “locked-in” to their current EHR technology. This could ultimately impede innovation and is a key aspect of the EHR technology market that requires significant maturity. With these considerations, we seek responses to the following questions:This request is naive, in that it focuses primarily on clinical data used to document encounters in questions 1 and 2. In terms of what constitutes tolerable loss with respect to clinical history, that really depends on the healthcare provider. Just looking at what providers are willing to tolerate with respect to transitioning from paper records, I've seen some that scan all at once, others scan for each patient on their next visit, some only scan the last year's history, others scan all data they have, and some just do the last visit. Some also reenter a complete history (e.g., as my provider did on his transition from paper), so there are a variety of levels for what providers will tolerate.
- Is EHR technology capable of electronically providing a sufficient amount of a patient's health history using summary of care records formatted according to the Consolidated CDA for the scenario described above?
- Is all of the data in a provider's EHR #1 necessary to migrate over to EHR #2 in the event the provider wants to switch? We recognize that medical record retention laws affect the provider's overall approach in terms of a full archived data set, but our question seeks to determine whether the loss of some data would be tolerable and if so, which data?
- Considering the standards we have adopted and propose for adoption in this rule, we request comment on what additional standards and guidance would be necessary to meet these market needs for data portability, including the portability of administrative data such as Medicare and Medicaid eligibility and claims. Additionally, we are interested in commenters' thoughts related to an incremental approach where a specific set of patient data could be used as a foundation to improve data portability for the situation described above as well as other situations.
- Does the concept of a capability to batch export a single patient's records (or a provider's entire patient population) pose unintended consequences from a security perspective? What factors should be considered to mitigate any potential abuse of this capability, if it existed?
The documents described in the Consolidated CDA guide are really designed to summarize the important outcomes of an encounter, or perhaps an episode of care. They were never designed to function as an EHR dump (nor was CCR for that matter). That doesn't mean some people haven't tried to use them that way. I've heard reports from one person on Twitter that he's aware of on EHR that dumps their entire patient history into a multi-megabyte CCD.
ONC does then attempt to address administrative data, in question 3. But they fail to account for operational data related to dynamic transactions (orders and payments), quality measurement, master file content, or user and access control information. One of the challenges in quality measurement today (and which is currently being looked at by both the HIT Standards and Policy Committees), is the disconnect between CQM data and EHR data. There are many questions of intent explicit in CQMs that aren't captured in the EHR, often because they are questions of clinical judgement, (e.g., medical appropriateness), In a system or workflow where the intent is to document what has been done (or in some cases not done), often what is not captured is why, and that is often the focus of exceptions in CQMs. So, the documents will have the what, but not often the why.
With regard to question 4, of course there are consequences that must be addressed and mitigations necessary. Whenever you add new functionality to a product, you need to perform a risk assessment. I would hope that should be obvious. I won't get into what those issues are because I'm not a security expert (although John Moehrke is).
In summary:
So much data goes into the configuration of an EHR, including test compendiums, medication formularies, order processing (including prescriptions), referral networks, data needed to conduct transactions, workflow configurations, clinical decision support configurations, documentation templates, et cetera. The patient's clinical data is but one component of the data needed.
The real challenge in transitioning is not exchanging clinical data that it manages, but rather, it is in configuring the EHR (which is more of a platform rather than an application) to match the processes of the healthcare provider, and to ensure that the data management supported by the EHR matches those processes.
Are there any other products where such a transition is possible? Can you just dump all of your SAP data and move it over to Oracle's CRM solution, or to Salesforce.com? (Unlikely) How about HR Management system? (Also unlikely) What about your business accounting data; could you just dump your info from one accounting system to another? (It depends on size of the organization and scale of the system -- for anything over small business size, not readily).
Tuesday, April 17, 2012
MeaningfulUse Stage2 and Smoking Status Vocabulary
At the S&I Framework Face to Face meeting last week, Rich Elmore kept pushing for a value set for smoking status. I had tried to craft one from SNOMED CT and failed, because it seemed to me that there were some missing concepts. Cecil Lynch (a member of the HL7 Vocabulary Workgroup) succeeded where I had failed (he knows SNOMED CT and vocabulary in general so much better than I do). He came up with this list which I think is an awesome mapping. We should all be proposing this value set and SNOMED CT for the exchange of Smoking Status information.
Thanks Cecil!
Keith
Thanks Cecil!
Keith
Text | SNOMED Code | SNOMED Text |
Current every day smoker | 449868002 | Smokes tobacco daily (finding) |
Current some day smoker | 230059006 | Occasional cigarette smoker (finding) |
Former smoker | 8517006 | Ex-smoker (finding) |
Never smoker | 266919005 | Never smoked tobacco (finding) |
Smoker, current status unknown | 266927001 | Tobacco smoking consumption unknown (finding) |
Unknown if ever smoked | 405746006 | current non smoker but past smoking history unknown (finding) |
HL7 mHealth Follow Up
This crossed my desk recently. HL7 really wants to be engaged in the mHealth space and is encouraging its members to participate.
| ||||||||||||||||||||||||||||||||
Clinical Quality Workgroup -- Essential Elements Tiger Team
The HIT Standards Clinical Quality Workgroup is rapidly closing in on its initial recommendations for making value sets accessible. We reviewed 4 recommendations on our call yesterday:
Within our scope was making recommendations in support of a short-term value set infrastructure enabling Stage 2 quality measure deployment. Out of scope was the longer term infrastructure.
The recommendations we discussed are listed below briefly.
- Establish NLM as a single authority to validate value sets used in Stage 2 quality measures.
- Ask ONC to expedite recommendations made by the workgroup in January this year (especially see slide 20) and by the Vocabulary Task force in April of 2010 (powerpoint).
- Specify the standards to use for exchange of value sets. Two choices were presented:
- IHE Sharing Value Sets
- HL7/OMG Clinical Terminology Services 2.0
- Enable web access for human and machine readable consumption.
On the first two topics, the workgroup appeared to be in good agreement.
CTS2 and IHE SVS
I was caught a bit off-guard with respect to recommendation #3 becausethe workgroup had already developed a consensus on recommending the IHE SVS profile on the call last week. It appears that there were some observers that were concerned about the use of that profile, especially since such a recommendation appeared to exclude the use of CTS in the architecture (even though it doesn't as I explain below).
The situation is a bit confusing for many: The IHE Sharing Value Sets profile is a simple implementation of two of the APIs described in the CTS 1 and CTS 2 specifications. It is designed for a very simple use case of searching for and downloading value sets. It is NOT designed to support broad management capabilities needed to maintain, validate or curate value sets.
The CTS standard originated as version 1.0 in HL7. CTS 2.0 became a joint HL7/OMG work effort, with HL7 defining essentially a functional specification, and OMG defining an implementation of that functionality. This pattern has been used in many HL7 / OMG collaborations.
I think the reason that the workgroup struggled with the question is because the scope was sharply defined with respect to implementation urgency. If you are going to develop a vocabulary (value set) maintenance infrastructure, you should be applying an architecture that accounts for standards like CTS, whether your view be short term or long term. However, regardless of what the architecture is, for the purpose of deployment of value sets to Health IT systems. They don't need an extensive API in order to access identified value sets. What they need is very simple.
As always, when posed with an either/or question, the answer is usually to restate the question. Both CTS2 and IHE SVS are pertinent and appropriate for the infrastructure. The Infrastructure should be oriented around CTS (long term), but APIs to access and download value sets should include IHE SVS (short term).
Enabling Web Access
On the final recommendation, the workgroup also struggled a bit. We kept falling into the trap of solution vs. requirement. The key requirement for web access is that there be a single source of truth for value sets. Whether that requirement is met by a single host (web site) through which access is granted, or multiple hosts accessing a singular database or service supplying the content, or a model of deployment supported via replication or federation is not material. We were well in agreement on there being a single source of truth for value set deployment but kept getting confused in drafting our recommendation by specifying solutions that meet that goal.
Coordination
There was insufficient time for me to bring up one issue that I am concerned about. At present, NLM, AHRQ, CDC and ONC are all expending efforts on managing vocabulary and/or value sets for a variety of different purposes. I'd like to see better use of HHS resources applied to the management of vocabulary and value sets, without so much duplication of effort.
Monday, April 16, 2012
Developing a SQL Schema for QueryHealth
In my SQL Implementation for Query Health post I showed how one could transform an HQMF Formatted Query into a set of SQL statements that would evaluate to a result for a given query. We reviewed that implementation in more detail last Thursday at the S&I Framework Face to Face. One of the outcomes of that review was that we decided to document a target schema for a SQL implementation.
There are several pilots or potential pilots that are interested in implementing against a SQL database in the Query Health Project. Each of them uses a different schema. We could have picked one of those, or just chosen one to be suitable for the purposes of a reference implementation. What I've done is gone through my SQL implementation code again, and documented a target schema that would be suitable for a rewrite of that against the new HQMF schema that Query Health created.
What follows is the basic description of a target database schema. This schema is NOT intended to support a full EHR as it does NOT support all of the details such a system would need. It is intended to support a representation of the data that Query Health could operate against. So, we don't track which organization an order was placed with for example, or the current status of the order
Of the tables (or views) listed above, only Encounter could never reasonably have a value for for encounter. That wasn't enough of an excuse to special case encounter. While it seems unlikely that you would document NOT recording a demographic, obtaining a lab result, or blood pressure, or ordering a procedure or medication, it's certainly possible that might be done, especially in certain contexts associated with quality measurement.
Demographics, Results, Vital Signs, Family and Social History and Problems or Allergies have some common features. They are stored in question/answer form, where code and coding system capture the code associated with the question (what is the patients: ethnicity, HgA1C, Pulse, FH of Heart Disease, or Smoking Status). The answer part needs to be captured in a structure that could record a number, physical quantity, string or coded value.
The questions associated with problems are things like complaint, symptom, finding, or type of diagnosis, and provide a more detailed classification. With allergies, you might classify it as an intolerance, a true allergy, or adverse reaction for which more details are needed, and you might also classify by type of substance (e.g., food, medication, or environmental substance).
For the case of Family History, the question would be expressed using a coding system for a disease, and the answer would be expressed as a (coded) family relation for whom the disease condition did (or if negated, did not) exist.
That structure is pretty straight-forward and appears below:
The type field tells you whether the value of interest appears in value or StringOrCode, and whether Unit or CodeSystem columns are relevant. The Intepretation flag only shows up on some values and indicates whether the value is considered to be abnormal in some way (e.g., high, low, et cetera).
There are several pilots or potential pilots that are interested in implementing against a SQL database in the Query Health Project. Each of them uses a different schema. We could have picked one of those, or just chosen one to be suitable for the purposes of a reference implementation. What I've done is gone through my SQL implementation code again, and documented a target schema that would be suitable for a rewrite of that against the new HQMF schema that Query Health created.
What follows is the basic description of a target database schema. This schema is NOT intended to support a full EHR as it does NOT support all of the details such a system would need. It is intended to support a representation of the data that Query Health could operate against. So, we don't track which organization an order was placed with for example, or the current status of the order
| Table | Purpose |
| Demographics | Demographic values (name, birth date, gender, race, ethnicity, address, et cetera). |
| Problems | A list of problems and diagnoses |
| Allergies | A list of allergies associated with the patient. |
| Medications | A list of the medications that the patient is or has been on. |
| Immunizations | A list of the immunizations that the patient has been given. |
| Procedures | A list of procedures that have been performed |
| Encounters | A list of encounters that have occurred |
| Results | A list of lab test results the have been generated |
| VitalSigns | Vital signs that have been recorded. |
| FamilyHistory | Family history associated with the patient. |
| SocialHistory | Social History observations associated with the patient. |
| Orders | Non-medication orders that have been made. |
| Rx | Medication orders that have been made. |
Each of the values in the first column corresponds to one of the definitions associated with a data criterion in the HQMF. In the HQMF to JavaScript translator, these become objects in a Green C32 JSON Object Model that is created based on CCD or CCR documents provided for patients. In the HQMF to SQL translator, these will become tables in a view that enables execution of the SQL Query.
There are a couple of ways in which these tables could be "populated". One could simply create views for each of the tables above in an EMR database. Each view would generate the appropriate content. Another mechanism would be to have an Export/Transform/Load process dump the data from the EMR database to tables in this format.
Each of the tables starts with the same set of common columns:
| Column | Type | Description |
| PatientID | char(36) | The patient for whom this row is associated. |
| ID | char(36) | A unique ID for the row. |
| Code | char(20) | A code for this entry. |
| CodingSystem | char(128) | The coding system for this entry (in OID format). |
| TimeLow | TS | The low value of the effective time for this row. |
| TimeHigh | TS | The high value of the effective time for this row. |
| ProviderID | char(36) | A unique identifier for the provider responsible for this row. |
| EncounterID | char(36) | A unique identifier for the encounter in which this row was created. |
| Negation | boolean | A flag indicating that the documented act was NOT performed. |
Of the tables (or views) listed above, only Encounter could never reasonably have a value for for encounter. That wasn't enough of an excuse to special case encounter. While it seems unlikely that you would document NOT recording a demographic, obtaining a lab result, or blood pressure, or ordering a procedure or medication, it's certainly possible that might be done, especially in certain contexts associated with quality measurement.
Demographics, Results, Vital Signs, Family and Social History and Problems or Allergies have some common features. They are stored in question/answer form, where code and coding system capture the code associated with the question (what is the patients: ethnicity, HgA1C, Pulse, FH of Heart Disease, or Smoking Status). The answer part needs to be captured in a structure that could record a number, physical quantity, string or coded value.
The questions associated with problems are things like complaint, symptom, finding, or type of diagnosis, and provide a more detailed classification. With allergies, you might classify it as an intolerance, a true allergy, or adverse reaction for which more details are needed, and you might also classify by type of substance (e.g., food, medication, or environmental substance).
For the case of Family History, the question would be expressed using a coding system for a disease, and the answer would be expressed as a (coded) family relation for whom the disease condition did (or if negated, did not) exist.
That structure is pretty straight-forward and appears below:
| Column | Type | Description |
| Type | char(10) | Type of value recorded |
| Value | real | Numeric Quantity |
| Unit | char(10) | Units of Measure for Physical Quantities |
| StringOrCode | char(36) | String or code values |
| CodeSystem | char(128) | Code System associated with codes |
| Interpretation | char(20) | Interpretation Flag |
The type field tells you whether the value of interest appears in value or StringOrCode, and whether Unit or CodeSystem columns are relevant. The Intepretation flag only shows up on some values and indicates whether the value is considered to be abnormal in some way (e.g., high, low, et cetera).
Any of the Medication, Immunization, Result, Procedure or Encounter rows could have been performed as the result of an order. Ideally, there would be a way to track the relationships of these items back to the order.
Now, having done this much analysis, there are several ways to build a schema that meets the requirements expressed. I could have a fact table, a value table, and an order relationship table, and add to the fact table the type of fact using the table column from the first table in this post. Or, I could build the 13 tables described in that first table, including the columns in the second, and adding the value table and order relationship where necessary. The former structure (a star schema) is closer to a data mining/data warehouse schema used by I2B2. The latter is closer to what might be used by an EMR system.
The point of query health is to send the question to the data. It could live in a data warehouse or in an individual EMR. If it lives in a data warehouse, then there are clearly some skilled technology resources who can figure out the mapping from an EMR structure to a warehousing oriented structure, but the reverse is not true. So, I would go with the second choice, creating an EMR-like schema an put all the necessary values for each table in a single row (for simplicity). That makes it easier for an EMR to map to the schema, a little bit harder for a system like I2B2 (but for which there are more skilled resources available), so in general, a good balance.
Here's the final structure I decided to work with for the new HQMF to SQL translator. Note that there are several other small optimizations included. I don't bother to associate demographics with a specific Encounter ID for example. Since allergies and problems always answer with a code, you don't need type, value and unit, but since vital signs are always physical quantities, you never need to know the type or have a place to store coded results, for example.
Now, having done this much analysis, there are several ways to build a schema that meets the requirements expressed. I could have a fact table, a value table, and an order relationship table, and add to the fact table the type of fact using the table column from the first table in this post. Or, I could build the 13 tables described in that first table, including the columns in the second, and adding the value table and order relationship where necessary. The former structure (a star schema) is closer to a data mining/data warehouse schema used by I2B2. The latter is closer to what might be used by an EMR system.
The point of query health is to send the question to the data. It could live in a data warehouse or in an individual EMR. If it lives in a data warehouse, then there are clearly some skilled technology resources who can figure out the mapping from an EMR structure to a warehousing oriented structure, but the reverse is not true. So, I would go with the second choice, creating an EMR-like schema an put all the necessary values for each table in a single row (for simplicity). That makes it easier for an EMR to map to the schema, a little bit harder for a system like I2B2 (but for which there are more skilled resources available), so in general, a good balance.
Here's the final structure I decided to work with for the new HQMF to SQL translator. Note that there are several other small optimizations included. I don't bother to associate demographics with a specific Encounter ID for example. Since allergies and problems always answer with a code, you don't need type, value and unit, but since vital signs are always physical quantities, you never need to know the type or have a place to store coded results, for example.
| Table | char(36) | char(36) | char(36) | char(128) | TS | TS | char(10) | real | char(10) | char(36) | char(128) | boolean | char(10) | char(36) | char(36) | char(36) |
| Demographics | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | StringOrCode | VCodeSystem | ProviderID | |||||||
| Problems | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | StringOrCode | VCodeSystem | Negation | EncounterID | ProviderID | |||||
| Allergies | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | StringOrCode | VCodeSystem | Negation | EncounterID | ProviderID | |||||
| Medications | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Negation | EncounterID | OrderID | ProviderID | ||||||
| Immunizations | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Negation | EncounterID | OrderID | ProviderID | ||||||
| Procedures | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Negation | EncounterID | OrderID | ProviderID | ||||||
| Encounters | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Negation | OrderID | ProviderID | |||||||
| Results | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Type | Value | Unit | StringOrCode | VCodeSystem | Interpretation | EncounterID | OrderID | ProviderID | |
| VitalSigns | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | Value | Unit | Interpretation | EncounterID | ProviderID | |||||
| FamilyHistory | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | StringOrCode | VCodeSystem | Negation | EncounterID | ProviderID | |||||
| SocialHistory | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | StringOrCode | VCodeSystem | Negation | EncounterID | ProviderID | |||||
| Orders | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | EncounterID | ProviderID | ||||||||
| Rx | PatientID | ID | Code | CodeSystem | TimeLow | TimeHigh | EncounterID | ProviderID |
Friday, April 13, 2012
It's been way to long...
It's been way to long since I issued one of these...
I write in XSLT. It's an arcane language. I work with HL7 Version 3. It's also an arcane language. I use the two together in ways that few would ever consider. I know the ins and outs of these arcanities because of hard won experience. I can teach that, but sometimes I just don't have time. This has been especially true given my focus on new Meaningful Use regulations over the past month or so. But sometimes, it's not my ability to teach, but rather, someone else's ability to learn that comes to the fore. This is especially true for this next recipient.
This next award goes to a fellow I didn't really know until a couple of months ago, and who I really hadn't spent much time with until a few weeks ago. He's been participating in Query Health. He's been somewhat quiet, but apparently absorbing quite a bit. I know from experience you have to watch those quiet ones. Then about a month ago the questions started showing up in my inbox. I'd written a translator that took the XML that I2B2 uses to represent a query and turned it into HQMF. It was sufficient for a demo at HIMSS, but needed additional work to support the rest of the ontology:
And I feel bad because I'm still behind on responding to three of his e-mails. Then we have a meeting, and I get to see what he's done. It isn't perfect, but this guy doesn't seem to know HL7 RIM well and probably hadn't even heard of HQMF until he started on this project. But thankfully, he's taken on a piece of work that I couldn't do for lack of time, and has done well -- quite well.
Who is this guy? I start looking around. A very interesting mix. What's really important is that he seems to dive in -- and succeed. I have a gut feeling about this guy, he explores broadly, but thinks deep ... this is not someone I know well, but someone that I really would like to know much better.
If you don't know Jeff, he seems to be one of those people that has a career to be jealous of. A little machine learning early in his career, a stint at MIT Media Lab (so jealous). He's directed some plays, three in fact. Looks like the NLP work he did in a clinical setting attracted him to Health IT. He followed that up by a PhD in Health Informatics, and was an NLM Fellow (they don't give those out to anyone -- I'll bet I know his advisor). He was doing cool stuff with CCD within a year of it's being released.
I write in XSLT. It's an arcane language. I work with HL7 Version 3. It's also an arcane language. I use the two together in ways that few would ever consider. I know the ins and outs of these arcanities because of hard won experience. I can teach that, but sometimes I just don't have time. This has been especially true given my focus on new Meaningful Use regulations over the past month or so. But sometimes, it's not my ability to teach, but rather, someone else's ability to learn that comes to the fore. This is especially true for this next recipient.
This next award goes to a fellow I didn't really know until a couple of months ago, and who I really hadn't spent much time with until a few weeks ago. He's been participating in Query Health. He's been somewhat quiet, but apparently absorbing quite a bit. I know from experience you have to watch those quiet ones. Then about a month ago the questions started showing up in my inbox. I'd written a translator that took the XML that I2B2 uses to represent a query and turned it into HQMF. It was sufficient for a demo at HIMSS, but needed additional work to support the rest of the ontology:
- How did you extract this? Answered that one.
- You know, when I looked at that, it is different. I think we're going to need to do this.
- You know that file you wrote... I made some changes to it so that it could support this other thing.
- Two days later: Here's some more stuff I wrote, tell me what you think of it.
- Next day, I think I understand this better, I made some more changes, can you look at this.
And I feel bad because I'm still behind on responding to three of his e-mails. Then we have a meeting, and I get to see what he's done. It isn't perfect, but this guy doesn't seem to know HL7 RIM well and probably hadn't even heard of HQMF until he started on this project. But thankfully, he's taken on a piece of work that I couldn't do for lack of time, and has done well -- quite well.
- Next day: OK, I fixed that stuff you told me about.
- Oh, here's another update --> He's added these three things and five more from this other space. (Look out, this one's a doer. If you aren't careful, his code is going to be on the main line and yours will be the branch -- that might not be so bad).
Who is this guy? I start looking around. A very interesting mix. What's really important is that he seems to dive in -- and succeed. I have a gut feeling about this guy, he explores broadly, but thinks deep ... this is not someone I know well, but someone that I really would like to know much better.
This certifies that
Jeff Klann of Partners
Has hereby been recognized for outstanding
contributions to Query Health.
contributions to Query Health.
If you don't know Jeff, he seems to be one of those people that has a career to be jealous of. A little machine learning early in his career, a stint at MIT Media Lab (so jealous). He's directed some plays, three in fact. Looks like the NLP work he did in a clinical setting attracted him to Health IT. He followed that up by a PhD in Health Informatics, and was an NLM Fellow (they don't give those out to anyone -- I'll bet I know his advisor). He was doing cool stuff with CCD within a year of it's being released.
Thursday, April 12, 2012
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:
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:
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.
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.
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.