HL7 Watch

Administrative Gender Code System: The Never Ending Story

noreply@blogger.com (Barry Smith) — Thu, 01 Feb 2018 19:12:00 +0000

*Subject:* Re: [vocab] Administrative Gender code system

On Tue, Jan 30, 2018 at 9:35 AM, Flores, Finnie

Hi John,Thanks for questions. At this point, we plan to publish this for our reference data model/dictionary (which eventually will be implemented in solutions).

Essentially the idea is to do this:

For Gender the HL7 codes and displays are:

M = masculine

F = feminine

For Sex at birth the HL7 codes and displays are:

M = male

F = female

UN = intersex

Is this permissible use of HL7 AdministrativeGender code system,

particularly associating a different display for the HL7 codes?

Thanks

Finnie

*Subject:* Re: [vocab] Administrative Gender code system

On Tue, Jan 30, 2018 at 9:36 PM, Lisa R. Nelson > wrote:

All,

This is a very good “case study” for how to determine when a new value set needs to be defined. My instincts say this is a case where the right answer is to create a new value set. However, it would be good to have some guidance from Vocabular which we could use as a “perk test” to make it possible for more people to rapidly apply the test and come up the same conclusion as to if a new value set is needed or not.

Proposed approach: As comparison questions for each concept:

1. Is “masculine” the same concept as “male”? No.

2. Is “feminine” the same concept as “female”? No.

3. Is “intersex” the same concept as “undifferentiated”? No.

If the concepts in the proposed “answer set” are not all semantic equivalents of the answers is the existing value set, then you need to make a new value set.

Is there a simple FAQ that explains how to determine if you need to make a new value set or not?

Lisa

*From:* Russ Hamm [mailto:russellhamm@gmail.com

*Subject:* Re: [vocab] Administrative Gender code system

This would not be an appropriate use of Administrative Gender which is defined as "The gender of a person used for administrative purposes (as opposed to clinical gender)" as there is a risk of these terms implying or changing the semantics of the existing codes.

It would be possible to add these as additional synonyms to Administrative Gender or create a separate value set to meet your use case via the Vocabulary Harmonization process.

-russ

*From:*Lloyd McKenzie [mailto:lloyd@lmckenzie.com]

*Subject:* Re: [vocab] Administrative Gender code system

From a practical perspective:

As much as humanly possible, we try to avoid multiple display names for v3 codes. The model and the tooling doesn't handle it well. As well, this is a set of codes that are extremely deeply used within v3 and have been established for almost 15 years. The code system always has been broken. "Yndifferentiated" should never have been a code in the AdministrativeGender code system - but it's not something we can reasonably yank or fix now. And if we were to do so, it wouldn't actually manifest anywhere - there are very few new v3 specs being created and those that do get updated will likely require the display names align with what was previously used.

If we were going to propose new display names (or codes) for something, the place to do that would be FHIR which isn't (quite) normative yet. FHIR has no concept for undifferentiated/intersex because that's not an administrative gender. I don't think we would change from male/female to masculine/feminine because those aren't "genders". They don't align with what gets captured in administrative systems, on drivers licenses, in passports or all the other places "administrative" gender is represented. Masculine/feminine sounds more like "social" gender to me - and that's a different element.

Lloyd

*Subject:* Re: [vocab] Administrative Gender code system

Am 31.01.2018 um 05:37 schrieb McDonald, Clem (NIH/NLM/LHC) [E]:

For the record, I think the choice of Undifferentiated a goofy mistake made out of haste and lack of subject matter content by whom ever made it. I believe the codes were M, F and U, and someone guessed wrong on U. Which always meant unknown by the recorder. Undifferentiated is a very specific term applied to new born infants. It is used when the care givers are asked to make a call on the gender (sex) of the child and the genitalia are in a midle state between Make and female – hence undifferentiated.

To: vocab@lists.hl7.org

*Subject:* Re: [vocab] Administrative Gender code system

On Wed, Jan 31, 2018 at 10:05 AM, Frank Oemig wrote:

Value Sets Management

We are currently working in the UTG and VSB projects to get a better understanding how value set management works. Everyone has an idea, but those vary. We need an information model to handle definitions, expansions, constraints, binding and usage.

Value Set creation

Of course, a value set can contain multiple codesystems, perhaps with the same codes from different codesystems. This is not an issue.

Administrative Gender

This term is misleading. It has nothing to do with patient gender. It is aka of room indication. So I agree with Lloyd and Clem. For that purpose "male" and "female" including "unknown" are enough. You could replace male and female with "room-mate male" and "room-mate female"...

Different Gender Interpretation Types

The problem with our gender discussion is that we never agreed on a common understanding. It has nothing to do with value sets, but code systems.

Some believe that patient administrative gender represents the gender of the patient. This is quite convenient, but wrong. This is the reason why we have introducted "undifferentiated" because some injects different views into this field. IMO, any statement about patient's gender - no matter which interpretation counts - should go into different observations. (This is what Clem implicitly said.) For that purpose we need different code systems. Most of them will contain a code for "male" or "female", but with different interpretations. Stating "male" is a different concept compared to my passport also stating "male". The display name is the same, the code may be the same, but the concept is definitely different. Therefore we need different code systems.

I believe moving in that directions will solve the problem. (So, please, review that URL although the contents is in German.) But I also know that staying with what we currently have and do is more convenient. Consequently, this discussion will come up at least every year again.

regards

Frank

On the Future of CDA

noreply@blogger.com (Barry Smith) — Thu, 24 Oct 2013 14:39:00 +0000

Another interesting post from Graham Grieve "On the Future of CDA". Graham argues that the current RIM-based strategy is over-complicated and that the CDA R3 team should focus on FHIR as vehicle in the future. See also these comments (emphasis added):

I have implemented CDA R2 from “the ground up” and I can honestly say that it is a real mess. The real problem is that it feels like it was designed by people who haven’t done much information designing in their careers; people who are experts in health care domains, but not in information design. Software people coming to the CDA for the first time are utterly baffled by its ornate, labyrinthine structures and quirky vocabulary.
I have also looked at all of the proposed replacements and none of them fix the inherent problems with the whole system. Any replacement needs to be completely modular, consistent, and without the arbitrary, almost random restrictions of the current model (why CAN’T you have a status element in the header for the whole report?). Modules need to be decoupled; none of these massive trees of schemas for each message. Vocab and schema structures need to be simplified and streamlined. All possible vocabulary should be included with the XML schemas for each module (or at least links to all the lookups), and the modules should be packaged separately (although a basic set can be package together as a “quick start”). I know, you’ll probably say FHIR is all this, but have you had non healthcare information designers look at it? You know, database designers. Business intelligence experts. Those folks. What did they say?

Great Post!!!
I am an “Implementer” and could not agree more with everything in Grahame’s post.
HL7 v3 (and by extension CCD/CDA) is overly complex, unintuitive and seems bent on maintaining an abstract data structure at the expense solving real world problems easily and quickly.
The incredible paucity of example CDA example documents from HL7 seems to indicate that even the standards developers have a hard time generating CDA documents.
Although I would hate to have to redo all the CCD/CDA development work we have already done, it seems like the best way to proceed if we can get something that is a better solution for the long term. I have very limited exposure to FHIR, but maybe this is what we have been waiting for.

Breath of Fresh Air for FIHR

noreply@blogger.com (Barry Smith) — Sat, 05 Oct 2013 02:11:00 +0000

From Clinical Statements Task Force

On Fri, Oct 4, 2013 at 9:05 AM, Lloyd McKenzie wrote:

... While you *could* pursue a RIM-based repository for FHIR, it's hard to imagine why you'd want to and the presence of extensions would make it quite complicated.

Lloyd

On Thu, Oct 3, 2013 at 8:20 PM, Grahame Grieve wrote:

hi Lloyd

> it's hard to imagine why you'd want to

I find it quite easy - because you've already invested a lot of work in one.

And there are a number of people who already have. I invite all of you to help work on the RIM Mappings for the existing resources that are of interest to you - they've fallen behind, and fundamentally this is driven by a lack of implementer interest in them.

Grahame

On 4 October 2013 03:25:36 CEST Bob Dolin wrote:

To: Lloyd McKenzie , Grahame Grieve

Hi,

A bit late to the discussion.

Lloyd, are you asking why we should be mapping FHIR resources to the RIM?

Thanks,

Bob

On Thursday, October 03, 2013 6:23 PM Lloyd McKenzie wrote:

To: Grahame GrieveCc: Rik Smithies; Zel, M van der; Haarbrandt, Birger; RIMBAA; Clinical Statements Task Force

If you have one already, then yes it may make sense to use it. However, if you're coming at the problem new ..., I'm not sure what using a RIM back end for FHIR would buy you. Not saying it wouldn't buy you anything, just that I can't see it.

Lloyd McKenzie

An OGMS-Based Model for Clinical Information

noreply@blogger.com (Barry Smith) — Mon, 15 Jul 2013 17:56:00 +0000

In a paper presented at the International Conference on Biomedical Ontology (ICBO) in Montreal, Heiner Oberkampf and colleagues from Siemens Corporate Technology and the Universities of Augsburg and Erlangen propose an interesting strategy to advance semantic integration of patient data. As they point out, such integration would require annotation with terms from established domain ontologies "based on an ontologically well-founded information model" and they choose Ontology for General Medical Science (OGMS) as the basis of their work.

Among several other ICBO papers devoted to the creation of OGMS-conformant clinical ontologies was a contribution by Josh Hanna and colleagues at the University of Arkansas for Medical Sciences entitled "Building a Drug Ontology based on RxNorm and Other Sources." DrOn is built in a modular fashion to facilitate incorporation of content from RxNorm and other sources within a manually built, realist, upper-level framework based on BFO.

Ontology for General Medical Science vs. HL7 RIM

noreply@blogger.com (Barry Smith) — Tue, 02 Jul 2013 13:57:00 +0000

The Ontology for General Medical Science (OGMS) is intended to provide a very simple framework for representing the entities involved in a clinical encounter. It starts out from what the supporters of OGMS take to be a commonsensical distinction between

1. entities on the side of the patient, for example diseases, conditions, symptoms, states of health or disease

2. entities on the side of the clinician, for example diagnoses, observations, records, clinicians' acts.

As has been asserted ad nauseam since the very beginning of this blog, HL7 RIM is based on a denial of this distinction. For the RIM, diseases, conditions, symptoms are what HL7 calls 'Observations'.
In a recent post to the HL7 Patient Care Work Group reproduced below, Kevin Coonan has rediscovered some of the basic ideas currently exercising the developers of OGMS (see, most recently, here). But because he is still working within the RIM framework, he has at the same time revealed the degree to which this framework causes problems when the attempt is made to formulate these basic ideas and thereby to generate a coherent strategy for coding the corresponding information.

As Kevin points out, for HL7 'Condition' means an "Observation, event or risk, whose value is a clinical finding or disorder that represents an undesired state of health which names--provides the clinical semantic for--a Health Concern.

We shall focus, first, on the identification of a Condition as an "Observation, event or risk". This seems, from an ontological point of view, to be a dangerous mixing of categories.

It is for example not clear to me how an 'event, or risk' can 'name' an undesired state of health. Nor how an event, or risk, can provide a 'semantics' for a Health Concern. (Nor is it clear to me what 'Health Concern' is intended to mean.) However, if we focus just an 'Observation', then we can make some sort of sense from the definition provided. Observations have values -- clinical findings, which is to say findings on the side of the clinician -- representing undesired states of health on the side of the patient.

The Condition, for the RIM, is something on the side of the clinician, and has a Condition.effectiveTime, which may for several reasons 'be open or null, including someone forgetting to record when you no longer had that liver laceration.' The Condition is then not the liver laceration. It is (something like) the recording of the liver laceration. But then in regard to the Condition of acute stroke, Kevin tells us that he would put as endpoint 'the time that the stroke stopped progressing'. Thus (we are tempted to say): the Condition can end in two ways; when the stroke stops progressing; or when the clinician stops bothering to record its progression.

From: "Kevin Coonan, MD"
Subject: Health Concerns: clinical status of the naming Condition -- RFC/RFI
Date: 1 juli 2013 23:21:00 CEST
To: "Patient Care Work Group" patientcare@lists.hl7.org

One topic which comes up any time we talk about Health Concerns (e.g. "Problems"), is how to represent the clinical status (activity) of the Condition (Condition here meaning an Observation, event or risk, who's value is a clinical finding or disorder that represents an undesired state of health which names--provides the clinical semantic for--a Health Concern). One thing I don’t address is the relevance to the current context.
Given how long this has been a ‘problem with problems’, we must be missing something from earlier discussions, hopefully a solid solution. This is not just gilding the lily or syntactic sugar. This is a real thing we need, likely as a component Observation of the Condition. Like so many (all?) things in clinical and biomedical informatics, simple solutions (e.g. binary, isActive; simple value sets like “active”, ”resolved”, ”inactive”) reflect insufficient analysis of how these are used and what information is used by a clinician, given a specific context, to determine whether or not some Condition belongs on the problem list, and if so, whether or not it is “active”. There are other uses besides populating a problem list, and requirements for other patient care decision making, clinical decision support, billing diagnosis coding, research, public health reporting, etc. need to be considered.

Example: If you have an acute MI or stroke you may really benefit (live) if given anticoagulant and/or fibrinolytic therapy. If you have “active” gastrointestinal or other non-compressible bleeding

(e.g. hepatic or splenic injury e.g. 65324009| Minor laceration of liver without open wound into abdominal cavity (disorder) |)

your risk of complications alters the calculus to determine if the potential benefit outweigh the potential harm. Knowing whether or not your “grade II liver laceration” is an active problem may determine whether you live or die. I also would not depend on the Condition.effectiveTime.high, since there are several reasons why this may be open or null, including someone forgetting to record when you no longer had that liver laceration. Many other conditions may not have such a nice endpoint to record, e.g. it would be hard to figure out what to put there for an acute stroke. I would put the time that the stroke stopped progressing, focusing on the vascular aspect. Others might use the time signs and symptoms resolved, focusing on the neurologic impact. Still others would just leave it blank, because neither of the two end points make much sense for a stroke. Also, we likely want something other than Condition.effectiveTime.high.lessThan(now()) to determine what shows up in the problem list.

We know that it is an error to try and use Act.statusCode for this, since that just tells you the status of the observation, and is nearly always 'completed' (i.e. you made the observation) or 'obsolete'. (i.e. the observation you made before was replaced by a different one, e.g. to correct an error).

Here is a sketch of the semantic I have been toying with. It has some overlap with SNOMED-CT Clinical finding (or Disorder) clinical course and episodicity concept model attribute, but not precisely. Part of the design grew out of frustration with trying to use those two attributes.

I think it is multi-hierarchical, and dimension/property values which at first seem to be exclusive of each other often are not. My (albeit limited) analysis suggests that some problems are both active and inactive.
E.g. healed distal tibia fracture resulting in a compartment syndrome and chronic neuropathy has features of both--even splitting the fracture and compartment syndrome into two independent entries doesn't resolve this, but it does provide a use case to look at need for, rules, and representation of splitting a Concern into two (or more) and/or using multiple Conditions to name a Concern. Perhaps you could split further into “chronic neuropathy”, “compartment syndrome”, and “distal tibia fracture” (and if we do, do these belong to the same Health Concern, or do they name their own and what are the semantics of association between the them). If the compartment syndrome ran its course a decade back, but there are continued manifestations (e.g. contracture, loss of strength), we are faced with the same problem and now have to split the initial naming Condition into five Conditions, each linked by one or more ActRelationshipTypes. While you may not want to have to write those down every time you see the patient, a computer shouldn’t have any more difficulty with a patient who has five Health Concerns than just one, or for that matter, a patient with 5K (we can talk about why 5K is more useful than it sounds some other time).

I started by assuming there were going to be multiple defining dimensions/properties, and that the values for those dimensions/properties were likely fuzzy, and probably somewhat contextual. We don’t typically talk about speed of onset with a fracture, but definitely go into detail with something like a headache. One concept which is problematic (while SNOMED mentions this, it still doesn’t have the full capability to describe the different uses) is “acute”. Acute can mean sudden onset, early in the disease, and/or self-limiting. I tried to avoid its use in those cases where it could be ambiguous.

The defining dimensions/properties I came up with were:

1. Phase of disease, with early being relative (depending on the duration of the disorder) to the first half of the condition, and late being relative to the second half. So “late” into a common cold could be much shorter than “early” chronic renal insufficiency. I also added a third half, that of “preclinical” to represent disease activity. This starts with ‘risk’, e.g. if you inherit a brca1 gene, you don’t have breast or ovarian cancer, but, if you have those tissues in your body, you are at risk. You could, theoretically, follow this risk as culprit mutations accumulated in individual cells until true malignant transformation occurred. Even then you are going to have a significant period where you do not have detectable or definitively diagnostic disease. Similarly, myocardial ischemic disease doesn’t usually occur until after other disease processes have existed for some time (e.g. atherosclerotic changes to coronary arteries, systemic inflammation). In this preclinical period (or after, I suppose) you may have abortive disease where you never even know it (or may have had minimal symptoms, often non-specific, such as we see in a lot of infectious diseases, e.g. West-Nile Virus encephalitis and histoplasmosis occur in a minority of those infected, most people contain the infection w/ minimal nonspecific symptoms or are totally asymptomatic).

2. Stability addresses the homeostasis of the individual due to the disorder, not the disorder activity. The far ends are “stable” i.e. homeostasis preserved, to “unstable”, i.e. loss of homeostasis, usually with shock, injury to unrelated end-organs and death. I include a state of “metastable” meaning that between compensatory mechanisms and/or clinical interventions the individual is not at homeostasis, but is also not progressing towards death. This is a temporary (hence “meta-“) state, very energy consuming to maintain, and will eventually result in decompensation or stabilization. We see this all the time as “compensated shock”, as well as it being fairly common in injuries like high cervical spine fractures (where you may have no or minimal evidence of a cord injury, but excessive movement with low energy could result in serious if not permanent/fatal cord injury*) and splenic injuries.

3. Static v. dynamic addresses change is the disease activity, severity, course, or need for intervention. You can be static and be quite sick (as people die, fewer and fewer variables are needed to differentiate their physiology one minute to the next, and equilibrium with the environment is the eventual fate of us all). The difficulty is how to represent disorders which are episodic in nature. E.g. epilepsy in most people doesn’t show any sort of activity, until they actual have a seizure. Generalized seizures are quite dynamic, but the interictal period most decidedly dull. If you back up a step or two, you can look at (measure) seizure frequency, duration, and sensitivity to provocation (e.g. sleep deprivation) and end up with a picture of the disorder’s activity (with increased frequency, duration and/or sensitivity to sleep deprivation all marking an increase in the disease activity). So this needs some further refinement and thought. Maybe even a latent variable is lurking about and we need to tease out the hidden dimension.

4. Activity. This is what we started out thinking was the problem to be solved. It was in trying to define this that I ended up with the other dimensions surfacing as independent aspects. Obviously, acute Ebola hemorrhagic fever is an active problem. In those on the list, any history of benign neonatal jaundice is an inactive problem. My conceptualization is whether or not the pathogenesis and pathophysiology continues to occur, and/or manifestations of the disorder are evident. The hard cases are those disorders which are inherently episodic in nature (e.g. migraine headaches, asthma, seizures) where it is very hard to even detect the presence of the disorder most of the time (e.g. you can have “migraine headaches” which occur once every few years, so now that you haven’t had a MHA for two years, is this active or inactive?)

5. Chronic v. self-limiting/resolved. Typically, for a symptom, we set some time limit (6 weeks, a year, etc.) beyond which the disorder suddenly changes its character from acute to chronic

6. Course. Is the condition improving/resolving or getting worse/progressing. I tend to worry a lot more about things which don’t get better on their own.

If someone has the time, and/or a graduate student, having a literature review may be enlightening.
Thanks for any questions, comments, or criticisms.

Regards,
Kevin

Why Old Issues Regarding CDA Are Once Again New

noreply@blogger.com (Barry Smith) — Thu, 27 Jun 2013 14:57:00 +0000

In two posts from the last few days (here and here) I comment on recent intense exchanges within the HL7 CDA community concerning proper coding of clinical data using CDA. The reader is invited to examine these exchanges and to determine whether she agrees with me in the conclusion that HL7 CDA is, like the RIM on which it is based, so clunky, and so counterintuitive, as to threaten dangers for safety and security (dangers which become all the more worrying to the degree that HL7 CDA is associated with government edicts requiring its use).

Yesterday I added a further post, recalling Eric Browne's argument from January 2012 to the effect that this state of affairs is bringing about a situation where (to paraphrase only slightly)

we are in grave danger of setting in train a collection of safety and quality time bombs, spread around [the world] in a system of repositories, with no understanding of the clinical safety, quality and medico-legal issues that might be unleashed in the future.

As Grahame Grieve points out in his comment to this post, he had already responded to Eric's argument on his healthintersections blog in February of that year.

No news here, therefore; we should all just move along and get back to the more important issues of the day.

But what is Grahame's response?

Eric’s key issue is that HL7 CDA allows data to be supplied simultaneously in two distinct, yet disconnected forms – one which is “human-readable”, narrative text displayable to a patient or clinician in a browser panel; the other comprising highly structured and coded clinical “entries” destined for later computer processing.

As Grahame points out, CDA is built around the notion of the twin forms – a human presentation, and a computer processible version. But when Eric complains that clinicians have no way to inspect how the data and the narrative relate, nor is there an algorithm to test this, his response is

This is true – and it would be a whole lot more concerning except that this is true of all the forms of exchange we currently have – it’s just that they don’t have any human fall back to act as a fail safe check.

Thus the miserable complexity and clunkiness and unteachability of the structured part of HL7 CDA (thus of the HL7 part) are not a problem – because ... well, because of what?

Is it that HL7 CDA structured data is good because the problem of uncheckability (either by human beings or by algorithms) is faced by all attempts to create structured healthcare data?

Does experience thus far (including experience of panic on the strucdoc listserv in just the last few days) suggest that HL7 CDA is a good candidate to overcome this problem, given that we are all agreed that it needs to be overcome?

Critical Safety Issue for HL7 CDA

noreply@blogger.com (Barry Smith) — Wed, 26 Jun 2013 14:54:00 +0000

We have addressed (for example here and here) a number of what seem to be astonishingly difficult problems which face those who attempt to use HL7 CDA for coherent coding of clinical information.

In his "Critical Safety Issue for the PCEHR", Eric Browne makes clear why such problems may be of more general interest. Eric is talking here about the Australian Personally Controlled Electronic Health Record, but his warning (in bold below) is of much broader significance:

One major problem with HL7 CDA, as currently specified for the PCEHR, is that data can be supplied simultaneously in two distinct, yet disconnected forms – one which is “human-readable”, narrative text displayable to a patient or clinician in a browser panel; the other comprising highly structured and coded clinical “entries” destined for later computer processing. The latter is supposed to underpin clinical decision support, data aggregation, etc. which form much of the justification for the introduction of the PCEHR system in the first place. The narrative text may appear structured on the screen, though is not designed for machine processing beyond mere display for human consumption.

Each clinician is expected to attest the validity of any document prior to sharing it with other healthcare providers, consumers or systems, and she can do so by viewing the HTML rendition of the “human-readable” part of the document ( see the example discharge summary here). However, the critical part of the document containing the structured, computer-processable data upon which decision support is to be based is totally opaque to clinicians, and cannot be readily viewed or checked in any meaningful way. Moreover, I know of no software anywhere in the world that can compare the two distinct parts of these electronic documents to reassure the clinician that what is being sent in the highly structured and coded part matches the simple, narrative part of the document to which they attest. This is due almost entirely to the excessive complexity and design of the current HL7 CDA standard.

It seems to me that we are in grave danger of setting in train a collection of safety and quality time bombs, spread around Australia in a system of repositories, with no understanding of the clinical safety, quality and medico-legal issues that might be unleashed in the future.

As an illustration of the sort of problems we might see arising, I proffer the following. I looked at 6 sample discharge summary CDA documents provided by the National E-health Transition Authority recently. Each discharge summary looked fine when the human-readable part was displayed in a browser, yet unbeknownst to any clinician that might do the same, buried in the computer-processable part, I found that each patient was dead at the time of discharge. One patient had been flagged as having died on the day they had been born – 25 years prior to the date that they were purportedly discharged from hospital! Fortunately this was just test, not “live” data.

Why do HL7's Attempts to Create a Structured Clinical Document So Conspicuously Fail?

noreply@blogger.com (Barry Smith) — Thu, 20 Jun 2013 14:12:00 +0000

I estimate the total number of words posted to HL7's STRUCDOC (structured documents) listserv for the single day of June 18, 2013 to be in the order of 8,000. The Digest of these postings is provided below. (I do not provide the postings themselves, for reasons of space, though samples of earlier such exchanges are available, for example here.)

The general tone of these exchanges is a mixture of authority (from persons who have been participating in such email fora for a long time), concern (from persons new to HL7 who are interested in learning how to deal with sometimes difficult topics), puzzlement (from persons who wonder why these problems cannot be handled in a simpler and more intuitive way), and panic ("if HL7 generates such furious and seemingly interminable debates of such a high degree of complexity, how will we ever be able to safely use it to address the day-to-day practical problems that we face in coding healthcare information?" "How will we ever be able to teach people to use it?").

I have been asked to explain why I think HL7 generates debates of this sort, and I here provide a first list of what I believe to be the most important factors.

A. As argued from the very beginning of this blog, the RIM (Reference Information Model), which is the basis of HL7 V3, rests on a fatal confusion between model of information and model of reality. This brings the consequence that the persons involved in these debates lack a clear foundation for debate. I have argued at length that it is impossible to use the RIM to produce an intuitively satisfactory representation of any even modestly complex matter -- since parts of such a representation will relate to information about the world and parts to the world itself (for example to the condition of the patient). (Matters are made worse by the fact that the very framework obfuscates the difference between the two.)

B. This failure to provide intuitively satisfactory representations implies a failure in consistent understandability. This will mean that (for example) lists of codes and statements of coding principles will be understood differently by different individuals, some of whom will fight over whose interpretation is correct.

C. These fights will sometimes lead to adjustments to the principles. (They may even lead to improvements; some have even led to the addition of elements drawn from realist ontology to the HL7 framework.) Unfortunately, and perhaps most regrettably, the explications of these adjustments do not replace the existing HL7 documentation. Rather, they are simply inserted into the documents alongside the original, logically incoherent, formulations, as outlined here. This means that the result of such adjustments is that the HL7 documentation itself becomes logically ever more incoherent, leading to ever more furious debates over its interpretation.

D. The end-effect is that people leave, and when the new people who join start their work they have to rely on bloated and confused documentation -- but now without the benefit of having experienced the criticisms of shoddy work advanced (for example on this blog). And so the same mistakes are made all over again.

To see why such issues might be important for reasons other than morbid curiosity, see "Critical Safety Issue for HL7 CDA" above.

STRUCDOC Digest for Tuesday, June 18, 2013.

1. SUBJECT CHANGE: Debate about whether we need to deal with C-CDA reality
2. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
3. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
4. SUBJECT CHANGE: Debate about complexity of standards
5. Re: SUBJECT CHANGE: Debate about complexity of standards
6. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
7. Fix CDA's problems, don't encourage half measures. Was: RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set8. header >> race code ambiguity
9. RE: header >> race code ambiguity
10. Re: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
11. Re: header >> race code ambiguity
12. Re: header >> race code ambiguity
13. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
14. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
15. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
16. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
17. RE: header >> race code ambiguity
18. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
19. RE: header >> race code ambiguity
20. RE: header >> race code ambiguity
21. SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
22. Re: header >> race code ambiguity
23. RE: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
24. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
25. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
26. RE: Block Vote 06/20/2013: Structured Form Definition Implementation Guide Ballot Reconciliation
27. Re: header >> race code ambiguity
28. Re: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
29. RE: Block Vote 06/20/2013: Questionnaire Response Implementation Guide Ballot Reconciliation
30. RE: header >> race code ambiguity
31. Re: header >> race code ambiguity
32. Re: header >> race code ambiguity
33. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
34. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
35. Hijack Subject: Can we indicated "translation closeness" in CD
36. Re: Hijack Subject: Can we indicated "translation closeness" in CD
37. Re: Hijack Subject: Can we indicated "translation closeness" in CD
38. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
39. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
40. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
41. RE: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
42. Automatic Conference Call Reminder for Structured Documents

HL7 V3 Makes Great Strides in Providing a Clear Representation of Body Weight

noreply@blogger.com (Barry Smith) — Tue, 18 Jun 2013 13:43:00 +0000

BodyWeight has Device

Device is a coded description

Clothing is a coded description

BodyWeight has Clothing

BodyWeight is a physical quantity

BodyWeight has BodyWeight

From:

V3_DCM Models_R1_I1_2010Sep-BodyWeight-v1.08.pdf

What could go wroNg?

Meaningful Use of CDA When Medication Code is Unknown

noreply@blogger.com (Barry Smith) — Sat, 15 Jun 2013 23:35:00 +0000

What follows is a brief guide to those using CDA to address Meaningful Use Stage 2 requirements and who need to code information pertaining to use of a medication that is not included in any existing code set.

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org]
On Sun, Jun 9, 2013 at 8:53 PM, Tom de Jong ‹tom@nova-pro.nl› wrote:

Hi Keith, Brian,
I want to provide feedback from Pharmacy WG here, because I believe strongly that implementation guidelines for medication-related information should NOT be dependent on the carrier (i.e. a message or a document), when semantics should only be determined by the generic V3 backbone.
That having been said, it should most certainly be possible to leave the code empty (i.e. use a nullFlavor) when there is no official code available.
But I believe the proper nullFlavor to use is 'OTH', since the concept (i.e. medication type) is not codable within the value set that's available to you. It's perfectly OK to have a description of the medication type in the ‹originalText›. That leaves only one question: should it be necessary to state the RxNorm codeSystem OID? The current validators may require it, but
I believe it's against standing V3 datatype guidance. Technically, it would be useful to express the value set that the concept is *not* codable in, but I have always heard that using nullFlavor precludes using any other elements within the CD datatype, except ‹originalText›. Guidance on this should be
common across all of HL7, and should be documented at the level of the data type (i.e. not be dependent on the context of use). So both Pharmacy and SD WG have a good reason for getting this settled.

Best,
Tom

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On
Behalf Of Lloyd McKenzie
Sent: Monday, June 10, 2013 07:36
To: Tom de Jong
Cc: Boone, Keith W (GE Healthcare); Brian Weiss; HL7 Structured Documents;
pharmacy@lists.hl7.org
Subject: Re: Uncoded medication

Hi Tom,
Unfortunately it's *not* against standing data types advice. If you use the OTH null flavor in data types R1, codeSystem *must* be populated. It's a silly rule because it doesn't give you any useful information. Your value set may not draw from the whole code system you can't infer that the OTH means the code isn't from the specified code system. Furthermore, the value
set might span code systems.
The rule in Data Types R2 is a bit more reasonable. You must specify either the code system (in circumstances when the value set is "all codes from code system X") or a value set id. I still think it's a little onerous given that 90%+ of receivers aren't going to care. However at least it's useful information. However, for CDA R2, you're using Data Types R1.
Lloyd

From: Brian Weiss [mailto:brian.weiss@cdapro.com]
Sent: Tuesday, June 11, 2013 02:06
To: 'Lloyd McKenzie'; 'Kevin Coonan, MD'
Cc: 'Tom de Jong'; 'Boone, Keith W (GE Healthcare)'; pharmacy@lists.hl7.org;
'HL7 Structured Documents'
Subject: RE: Uncoded medication

Lloyd and Kevin,
I think we have to be clear here what context you are talking about:

1) RIM

2) CDA Normative Edition

3) C-CDA IG

4) TTT Validator

And then I think we also need to qualify if we are referring to "clear formal statement" (where we can cite chapter and verse from a published spec) vs. "intent".

For example, in the case of the TTT Validator, leaving something out that is a SHALL or SHOULD does NOT default to nullFlavor="NI", it generates an Error or a Warning (respectively). So, in that context, "technically" there is a big difference (meeting MU2 or not), indeed.
In the C-CDA IG, I also didn't think it was acceptable to leave something out that is a SHALL and have it default to nullFlavor="NI". If I'm right (not sure), this would not be something for which we ought to open a defect with the validator writers, either.
That doesn't mean your statement below is incorrect from a model standpoint - we just have to be clear what context we are talking about as there are different audiences on this listserv with different agendas. With all due respect to the folks working on the standards, an implementer tasked with achieving MU2 certification by their employer, really doesn't care at this point what the intent was, what the model says, etc. The only thing that really matters is the validator (and, whether it's legit to report something as a validator defect or not).
Brian

On Tue, Jun 11, 2013 at 3:32 PM, Tom de Jong ‹tom@nova-pro.nl› wrote:
Hi Grahame,
I think it's pointless trying to get harmony between CDA and pharmacy is pointless because the CDA expression is so limited, unless, that is, the pharmacy committee commits to working within the constraints that CDA imposes (not fun).
There are many cases where the CDA expression is just as rich as the one in the Pharmacy domain, i.e. rich enough to capture the proper semantics (more cases than where it is not). This is such a case. My point is: if both paradigms allow the same expression, we should use the same expression.
Ø There is - and always has been - a rule that if OTH is provided, then the codeSystem must be populated:
Ah, I’ve asked about that rule many times, but I was never pointed to it (and obviously never able to find it). I guess this is in the abstract data type spec, which explains why it was hard to find. Apologies for missing it, but I do understand why implementers say the spec is hard to crack.
Ø I'm sure you wouldn't otherwise think that simply because a rule is not enforced in the schema it's free to ignore, so I don't know why you think that here.
Like I said, I knew the rule was not enforced by the XML Schema. I looked for it in the XML ITS for the data type, but now know that I should have looked in the abstract data type spec. It would be REALLY helpful if data type rules like this would simply be listed as Schematron rules or even as template-style statements in the data type ITS. That way, we could simply ignore the abstract spec, which is what most implementers do anyway.
I’ll stay out of the rest of the discussion, because it’s very specific to the restrictions in the C-CDA spec.
Thanks,
Tom

Van: Victor Chai [mailto:victorchai01@gmail.com]
Verzonden: dinsdag 11 juni 2013 11:21
Aan: Tom de Jong
CC: Grahame Grieve; Lloyd McKenzie; Boone, Keith W (GE Healthcare); Brian Weiss; HL7 Structured Documents; pharmacy@lists.hl7.org
Onderwerp: Re: Uncoded medication
So end of this discussion, have we confirmed whether the below example from Keith valid in CDA?
Rgds
Victor Chai
‹manufacturedProduct classCode="MANU"›
‹templateId root="2.16.840.1.113883.10.20.22.4.23"/›
‹id/›
‹manufacturedMaterial›
‹code nullFlavor='UNK'
codeSystem="2.16.840.1.113883.6.88"›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
‹manufacturerOrganization›...‹/manufacturerOrganization›
‹/manufacturedProduct›

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Tom de Jong
Sent: Tuesday, June 11, 2013 13:15
To: 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'Brian Weiss'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Repeating from the main point in my original e-mail: the nullFlavor should be ‘OTH’. Other than that, the snippet is correct.
Best,
Tom

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 6:25 AM
To: 'Tom de Jong'; 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
I thought we said that with nullFlavor=”OTH” we would put in the codeSystem (and with nullFlavor=”NI” we would not)? Perhaps I misunderstood…
Brian

From: Lisa Nelson [mailto:LisaRNelson@cox.net]
Sent: Tuesday, June 11, 2013 15:38
To: 'Brian Weiss'; 'Tom de Jong'; 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Wow is this painful! I’m tracking with Brian on this… I thought we said that with nullFlavor=”OTH” we would put in the codeSystem (and with nullFlavor=”NI” we would not).
Further, I understand that the use of nullFlavor=”NI” (and no codeSystem) has the semantic meaning the corresponds to “No information about…”.
However, I’m having trouble inventing a sentence to capture the meaning that would correspond to a use of nullFlavor=”OTH” (with codeSystem). What would be the information in the human readable text to go with this machine readable entry? Is this the case where the medication is a medication that does not have a code in the specified value set? Value sets can have codes from different code systems, so how would I know which was the correct codeSystem to include? Is this a possible use case for nullFlavor=”OTH”? The IG specifies that this code SHALL come from value set ABC (CWE) and value set ABC has RxNorm and NDF-RT codes populating it. The medication I need to represent is some drug in a clinical trial that doesn’t have an RxNorm or NDF-RT code yet. I would encode the code element using nullFlavor=”OTH” with originalText=”Name-of-new-drug”. Is that right? What would I choose for the codeSystem attribute? Would I use the OID for RxNorm or NDR-RT?
If this isn’t correct, could someone please construct this scenario for me, and explain how we determine the correct codeSystem to use. I’m not clear on how we factor in the issue of a conformance to have the code come from a particular value set. The value set conformance seems to play a role in determining that nullFlavor=”OTH” is the correct encoding, but then I feel like I should be including the valueSet attribute rather than the codeSystem attribute to make the encoding for the code element really make sense.

Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaRNelson@cox.net

On Tue, Jun 11, 2013 at 9:34 PM, Brian Weiss ‹brian.weiss@cdapro.com› wrote:
Lisa,
Everything you wrote below seems correct and consistent with our discussion (which I think is converging) up to the point where you introduce a distinction between Value Set and codeSystem (with the example of a Value Set that includes multiple Code Systems like RxNorm and NDF-RT). I wasn’t aware that was the case in C-CDA – can you give some examples? If that is the case then I suppose it would be problematic to select one codeSystem for the nullFlavor=”OTH” case (since it is “other” relative to both).
So, this issue you have raised is one open question. Another is my question about what originalText should point to in the nullFlavor=”NI” case.
I think we have converged on the following so far (with the two open questions noted):
For the case where manufacturedMaterial is not in the codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
codeSystem="2.16.840.1.113883.6.88"› ‹!-- Lisa open question about what happens if valueSet corresponds to multiple codeSystems --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI'
‹originalText›‹reference value="#something"/›‹/originalText› ‹!-- Brian open question about what #something shoul point to --›
‹/code›
‹/manufacturedMaterial›
Brian

From: Victor Chai [mailto:victorchai01@gmail.com]
Sent: Tuesday, June 11, 2013 10:40 AM
To: Brian Weiss
Cc: Lisa Nelson; Tom de Jong; Grahame Grieve; Lloyd McKenzie; Boone, Keith W (GE Healthcare); HL7 Structured Documents; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
For the case where manufacturedMaterial is not in the codeSystem, and there is NO code avail, then codeSystem attribute shall be empty.
‹manufacturedMaterial›
‹code nullFlavor='OTH'
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the codeSystem, but there IS code avail, then codeSystem attribute shall be populated with the corresponding code system where the code is drawn from, e.g the below example where the code is from SNOMED CT, not from the required RxNorm code system.
‹manufacturedMaterial›
‹code nullFlavor='OTH' code="XXXX"
codeSystem="2.16.840.1.113883.6.96"›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
Rgds
Victor Chai

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Victor Chai
On Tue, Jun 11, 2013 at 10:50 PM, Boone, Keith W (GE Healthcare) ‹keith.boone@ge.com› wrote:
›From where do you get that specification?
According to abstract data types:
invariant(CD x)
where x.other {
x.code.other;
x.codeSystem.nonNull;
};
That implies that, when nullFlavor='OTH' (x.other above), that codeSystem must be present (x.codeSystem.nonNull).
Keith W. Boone

Sent: Tuesday, June 11, 2013 17:59
To: Boone, Keith W (GE Healthcare)
Cc: Brian Weiss; Lisa Nelson; Tom de Jong; Grahame Grieve; Lloyd McKenzie; HL7 Structured Documents; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
So what would you recommend to fill in codeSystem attribute for the this case?
For the case where manufacturedMaterial is not in the codeSystem, and there is NO code avail, then codeSystem attribute shall be empty.
Rgds
Victor Chai

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 18:18
To: 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Lisa Nelson'; 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
If there is only one codeSystem specified by the IG, I would of course specify that. That is typically the case, I believe. If we take the manufacturedMaterial example specifically, CONF 7142 says:
This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug Name Value Set 2.16.840.1.113883.3.88.12.80.17 DYNAMIC (CONF:7412).
As per Table 119 on page 304, that Value Set (2.16.840.1.113883.3.88.12.80.17) is draws from RxNorm. So, codeSystem=”2.16.840.1.113883.6.88”
Now, I think Lisa was saying that in some cases a Value Set can draw from multiple Code Systems, which is news to me (still need to get an example – Lisa?). But other than that, at least in a practical C-CDA context, I think that is the answer.
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 11:30 AM
To: 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Lisa Nelson'; 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
I was pleased to see that the validator was fine with an alternate codeSystem being used alongside nullFlavor=”OTH” as Victor suggested.
So, we now have three updated samples that reflect our convergence thus far (I’m suspending the multiple codeSystem question pending a sample from Lisa or otherwise):
For the case where manufacturedMaterial is not in the required codeSystem, but is in a different known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
code=”XXXX” ‹!-- whatever it is in the different codeSystem --›
codeSystem="a.b.c.d.e.f.g.h"› ‹!-- whatever the different codeSystem is --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the required codeSystem, and not in any other known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
codeSystem="2.16.840.1.113883.6.88"› ‹!-- the codeSystem required for this code --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
‹originalText›‹reference value="#something"/›‹/originalText› ‹!—Brian has an open question about what #something should point to --›
‹/code›
‹/manufacturedMaterial›
Additional comments welcome…
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Lisa Nelson
Sent: Tuesday, June 11, 2013 19:29
To: 'Brian Weiss'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Brian,
This is very good progress, but I am really struggling with the way you are wording the conclusions. The phrase, “not in the required codeSystem” is just not sitting well with me. Read any conformance statement in an IG and you will read that a code is required to come from a particular Value Set. The specification in an IG does not reference the code system in what it says is required. To make these conclusions work, I think we need to specify the value set and binding syntax that an implanter is up against in an IG. Otherwise, you leave a gap that implementers have to leap across for themselves.
For the case where manufacturedMaterial is not in the required valueSet and the binding syntax permits CWE, and there is a code for the concept in a different known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
code=”XXXX” ‹!-- whatever it is in the different codeSystem --›
codeSystem="a.b.c.d.e.f.g.h"› ‹!-- whatever the different codeSystem is --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the required valueSet and the binding syntax is CE, or the binding is CWE and the concept is not in any other known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='NA' ‹!-- Could this be NAV – temporarily unavailable, as it could become part of an updated version of the value set at a future time, if the value set were being sustained. --›
‹!-- the codeSystem is not required for this case --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
‹originalText›‹reference value="#something"/›‹/originalText› ‹!—Brian has an open question about what #something should point to --›
‹!—Lisa thinks the originalText should reference the statement in the narrative text which says, “No information available about medications.” --›
‹/code›
‹/manufacturedMaterial›
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaRNelson@cox.net

From: Brian Weiss ‹brian.weiss@cdapro.com›
To: 'Lisa Nelson' ‹LisaRNelson@cox.net›; 'Victor Chai' ‹victorchai01@gmail.com›; "'Boone, Keith W (GE Healthcare)'" ‹keith.boone@ge.com›
Cc: 'Tom de Jong' ‹tom@nova-pro.nl›; 'Grahame Grieve' ‹grahame@healthintersections.com.au›; 'Lloyd McKenzie' ‹lloyd@lmckenzie.com›; 'HL7 Structured Documents' ‹strucdoc@lists.hl7.org›; pharmacy@lists.hl7.org
Sent: Tuesday, June 11, 2013 10:39 AM
Subject: RE: Uncoded medication
Lisa,
Thanks to your e-mails, I’m gaining an appreciation for the problem in my interchangeable use of “Code System” and “Value Set”. I noticed that all the Value Set tables in the IG indicate “Code System(s):” – although as a practical matter there is always just one.
I’ve tried to switch my wording to “Code System specified by the required Value Set”. I think in a C-CDA IG context, that covers us. I want to limit my samples below to C-CDA IG as going beyond that is more than I feel I can handle, someone else can potentially look to expand this to generic CDA. And in terms of the broader case outside of C-CDA where someone defines a Value Set with multiple Code Systems, I think they will have to come up with some explicit guidance on what to do in terms of “OTH” – perhaps making one of the Code Systems “primary” or something like that, I don’t know.
I also see that you proposed an answer to my originalText question, thanks. I’m going to go with that unless someone else chimes in with something else.
I have not adopted your proposal re. “NA” or “NAV” instead of “OTH” – do you still think it is needed given the way the cases are defined below? Is there a need for another case.
Finally, I have not gotten into CWE vs. CE. Is this a practical issue in a C-CDA IG context? If not, I’m going to ask to defer it to whoever picks this up from a broader CDA perspective…
1) For the case where we don’t know the encoding of the concept in the Code System of the required Value Set, but have a code for it in a different Code System…
1A) …if we don’t know the code in the Code System of the required Value Set, but think it might exist:
‹manufacturedMaterial›
‹code nullFlavor='UNK'›
Since you are asserting that you don’t know what the specific type of manufactured material is, it is nonsensical (and not allowed) to also say what it is via the original text. Also, if you don’t have the CD.code specified, you cannot use translations. Translations are explicitly defined as a translation of the concept represented by the CD.code+codeSystem, which is not even allowed for UNK.
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹translation code="XXXX" codeSystem="a.b.c.d.e.f.g.h" /› ‹!-- whatever the different code and codeSystem is --›
‹/code›
‹/manufacturedMaterial›
1B) …if we believe a code doesn’t exist in the Code System of the required Value Set:
‹manufacturedMaterial›
‹code nullFlavor='OTH'›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
Translations are explicitly defined as a translation of the concept represented by the CD.code+codeSystem. If these are not present, translations are not used.
‹translation code="XXXX" codeSystem="a.b.c.d.e.f.g.h" /› ‹!-- whatever the different code and codeSystem is --›
‹/code›
‹/manufacturedMaterial›
2) For the case where we don’t know the encoding of the concept in any Code System:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
You must provide a code + code system (both)
codeSystem="2.16.840.1.113883.6.88"› ‹!-- the codeSystem required for this code --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
3) For the case where there is no information about the concept at all:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
You have no information, thus there is never an original text. Nothing else is allowed.
‹originalText›‹reference value="#noinfotext"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Kumara Prathipati
Sent: Tuesday, June 11, 2013 15:46
To: Brian Weiss; 'Lisa Nelson'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
Brian,
Thanks for the final clarity you are providing for this issue of "code not known" and various scenarios in that category..
I like the wording "Code System specified by the required Value Set" which eliminates confusion for any one who is not an expert in CDA.
Kumara

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Kevin Coonan, MD
Sent: Wednesday, June 12, 2013 03:54
To: 'Kumara Prathipati'; 'Brian Weiss'; 'Lisa Nelson'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication

All four examples are invalid.
There is a good deal of helpful information in the Core Principles and Properties of HL7 Version 3 Models, particularly section 5, which defines terminology binding. It is in the Foundation standards. In addition, reviewing the RIM and data types specification (data types r2 section 3.1.2, data types r1 1.11.4. Also see the usage notes in the vocabulary for NullFlavor. Also in Foundation standards) would have answered your questions.
Unless you are using a tool which constrains you to only saying things which are valid per the CDA XML Schema/templates and which prevents you from violating the basic semantics of HL7 v3, you will need to understand these parts of the standard in order to create valid examples. It is not reasonable to continue to expect to use the SD WG and pharmacy WG lists to continue to provide proof reading and tutorial services to you, or to listen to your complain when people don’t. Please avail yourself of the existing documentation and then feel free to ask any questions of the group. HL7 provides in-person training ‹http://www.hl7.org/implement/training.cfm?ref=common› (e.g. at WGMs and at educational summits) 6 times a year where you can get started. If you need additional tutoring, or custom training, there are many expert consultants within HL7 who provide this service. You may also wish to avail yourself of the well regarded CDA Academy ‹http://www.cdaacademy.com/› which Lantana offers in fall.
Keith, Lloyd, etc. correct me on the details of CDA r2 version of the data types & RIM (or my XPath grammar—been a while since I used it), etc. but the examples are not legal. If you assert that SomeClass@code is an exceptional value, it means that the information is not available. In these cases, you would not expect to see anything else. I.e. ‹code nullFlavor=UNK/› means you do not know the information which would be otherwise be conveyed by the attribute.
You cannot claim that an ManfuacturedMaterial/code@nullFlavor=anything other than INV or OTH and include ManfuacturedMaterial/code@code, ManfuacturedMaterial/code@codeSystem, ManfuacturedMaterial/code@valueSet or ManfuacturedMaterial/code/translation. Only in cases where ManfuacturedMaterial/code@nullFlavor= {INV|OTH|UNC} would you use ManfuacturedMaterial/code@origionalText .
You can state ManufacturedMaterial/code@code@nullFlavor=OTH, and specify the ManufacturedMaterial/code@codeSystem (and if relevant, you could also convey the value set) where the code could not be found. In the current datatypes/vocab, the correct nullFlavor when a proper code isn’t available in the source vocabulary is either OTH or INV.
I don’t recall if C-CDA (sorry, I am not where I can look it up) is still using the datatypes r1, where the only valid ManufacturedMaterial/code@code@nullFlavor is OTH. If you think there is a code in the code system, you need to look it up and use it, or just send the original text and state ManufacturedMaterial/code@code@nullFlavor=UNC. There isn’t a use case to send a coded value where you would assert that you are too lazy, or care so little that you are understood, that you couldn’t be bothered to look something up. The code either exists in the code system or it doesn’t. It either exists in the value set or it doesn’t. There isn’t any such thing as “I think there is a proper code”. Just send original text and hide your shame.
If the non-allowed concept doesn’t come from the required value set, you have two choices: say ManfuacturedMaterial/code@nullFlavor=OTH and then just provide the code and code system, or just drop the value set information (i.e. don’t assert membership in the value set) and don’t use an exceptional value at all. It will depend on the particulars of the template whether or not you need a value set assertion. If there is not any valid concept from any code systems at your disposal, then ManfuacturedMatieral/code@nullFlavor = INV/OTH, and just supply the original text. As mentioned, you could use the ManfuacturedMatieral/code@code@nullFlavor plus the code system to say which code system it could not be found in, but don’t send any translations in this case. Since this is only used with CNE, you really are not If the non-allowed code wasn’t in the value set, you would never say the ManfuacturedMaterial/code@code is OTH|INV and supply it as a translation. That is only done if the code isn’t in the code system. It never makes sense to say MaufacturedMaterial/code@code@nullFlavor=UNK. Use INV or OTH. UNC is the only other relevant nullFlavor value (it would not make sense to assert code.code = NI—you can do this on the RIM attribute, but as mentioned before, nothing else would be included. You just leave it out.
In the examples below, saying MaufacturedMaterial/code@nullFlavor=UNK means the sender doesn’t know what type of manufactured material was involved. Nothing else can be conveyed in MaufacturedMaterial/code.
Saying MaufacturedMaterial/code@nullFlavor=NI means you have no information. Nothing else can be conveyed in MaufacturedMaterial/code.
You[r] example MaufacturedMaterial/code@code@nullFlavor=OTH isn’t valid, since you didn’t supply a code to go with the code system—both are mandatory, i.e. MaufacturedMaterial/code@code@nullFlavor. Any time you use a CD datatype, you must either send a code plus code system, or leave both out. So you could make the expression valid by adding MaufacturedMaterial/code@code@nullFlavor=OTH (you would only do this if you wanted to be explicit which code system you couldn’t find the code in, but it seems duplicative, as this is only done when CNE, so there is a pretty good change the recipient either knows what should have been sent or they don’t care). In most cases you would just say MaufacturedMaterial/code@nullFlavor=OTH and send a valid, but non-allowed code + code system and/or original text. You can include translations to other code systems as you fancy. If MaufacturedMaterial/code@nullFlavor=OTH, you only include the original text, or some non-allowed code + code system, or both. But you have to commit to one of the these three valid options. NOTE: You only do this when binding is CNE. If it is CWE, then you do not use OTH, you just send the code/code system of your choice. In general, I would suggest that for coded values, it would be clearer to assert MaufacturedMaterial/code@code@nullFlavor=OTH only when there was a choice of code systems or when you wanted to send something else in the translation along with the original text, rather than MaufacturedMaterial/@code=OTH (In this case you would send the non-allowed code and code system, and any translations would be translations of the non-allowed code into other code systems, perhaps in hope that the recipient under stood one of them, although a phone call may be more effective).
If you don’t send a valid code (i.e. you say what code + code system), don’t send a translation. There may be an exception: if you really want to provide translations of a non-existent code into another code system(s) (i.e. you are effectively saying I could not find the code in this code system, but the concept that the code would have represented, had it been there, would be translated as such) and there is some ambiguity in the CNE specification which would make this useful to say which code system a valid code could not have been located. I don’t think this is a very good practice, but couldn’t find anything that said it was prohibited. It may be permissible to assert MaufacturedMaterial/code@code@nullFlavor=OTH and still include translations, and there may be an edge case to use it, but in general, this isn’t a good practice. (Lloyd? Looking for some help here. Is this even allowed? I couldn’t find anything that said it wasn’t.) I suppose if you wanted to say MaufacturedMaterial/code@code@nullFlavor=OTH and MaufacturedMaterial/code/translation@code= 74964007, @codeSysstem=2.16.840.1.113883.6.96, @displayName=other I wouldn’t get too dyspeptic. Regardless, unless both MaufacturedMaterial/code@code and MaufacturedMaterial/code@codeSystem are both present, you cannot send translations.
Regards,
Kevin

Subject: RE: Uncoded medication
From: "Brian Weiss" ‹brian.weiss@cdapro.com›
Date: Wed, 12 Jun 2013 09:00:01 +0300
X-Message-Number: 1

Kevin,
I didn’t really think I was using this list as a “proof reading and tutorial service” or as a sounding board for complaints. I was sensitive to the fact that the amount of volume I was generating on the list might not be welcome, which is why I set up a separate Google Group for working on my samples.
Keith asked a question about uncoded medication. It seems that even some of the folks who are past the “proof reading and tutorial service” stage were struggling a bit to crystallize the XML syntax for C-CDA that is required by MU2 when faced with the scenarios outlined (Keith’s original, and some additional ones that Lisa ably outlined better than I did earlier). I actually thought I was adding value here (as did a few others – though they also may be suffering from some of my obvious deficiencies).
Though I know I’m not worthy or qualified to critique one as erudite and significant a physician as yourself, might I humbly suggest to his worthiness, that after the competent, capable, properly versed folks here complete their discourse and summary – it might be beneficial to take a page out of my plebian playbook and actually provide the correct XML samples for the scenarios we outlined? With similar humility and recognition of the unreasonableness of further wasting your time, might I also suggest that if those examples don’t pass the TTT validator and/or are not unambiguously guided to by the C-CDA IG, it might behoove you and your fellow Olympians to ensure that suitable errata and defects are suitably registered, on the, perhaps remote (but nonetheless not entirely unfathomable) possibility that, otherwise, compatriots of mine amongst the unwashed masses might fail to get it right in the future?
J
Seriously, I get where you are coming from. I accept a lot of your critique. I think it’s a bit over-stated, but I can appreciate that the level of novice-level errors I make as I participate here can be frustrating/annoying. On the flip side, if you cut through some of that noise, I think we’re addressing some non-trivial things here (and Lloyd’s reply to you, highlights that even for the folks with much more experience and knowledge, this stuff is not so easy). I will try to work harder to improve my signal-to-noise ratio on this listserv. In my experience, public listservs are what they are… and they can get noisy… the good news is that you can always quickly see that an e-mail originates with me and just delete it without reading it.
The counter-critique here from me, having been paying close attention to the listserv for almost a year, is that there is a tendency here to leave the debate at the level of the model and theory and not adopt the required (in my view) rigor of translating the theory into XML examples. Yes, RIM and CDA are much, much more than C-CDA MU2 requirements, but I think you have to understand and accept that the floodgates are opening. HL7 and its leaders such as yourself should be very proud that you have advanced things to this stage – but success has its price. Being adopted by the US government as a mandated standard with billions of dollars indirectly tied to it, changes things.
It’s legit to try set the bar where you and other HL7 leaders want to set it for participation in this listserv. It’s SDWG’s listserv and its leadership should decide what does and doesn’t belong here. The world won’t end if I am barred from further participation (just ask me nicely, and I’ll go away, though I would like to ask for a refund on my quite steep HL7 membership dues in that case). But if there’s a notion that everyone is going to be signing up for Lantana’s CDA Academy, attending HL7 WGMs, and reading through the RIM foundational materials, as a pre-requisite for working on MU2-certified products or otherwise working effectively with C-CDA… that dog won’t hunt.
I really do respect and appreciate what you have done, and are continuing to do, to make HL7 and its standards work. That is ultimately much more important than my view of things, and my preferences. No hard feelings on my end – I hope none we can’t overcome on yours…
Thanks,
Brian

On Mon, Jun 10, 2013 at 12:50 AM, Brian Weiss ‹brian.weiss@cdapro.com›
wrote:
Tom and Lloyd,
Thanks so much for stepping up on this.
I want to remind us collectively that in addition to Keith's use-case below (which may be a great fit for "OTH") we also have the use-case of "No Information Available". I think nullFlavor="NI" is the only way to capture that without giving the erroneous impression that there is more information here than that.
Adding anything to the nullFlavor="NI" by definition adds no value (since there is no information and thus nothing more to really say). So, it's just down to meeting guidance and passing validators. Right now, the practical combination required in most caess is to add in codeSystem. So, that is
what we are currently doing in our samples. Should the ultimate guidance flowing form this thread (or otherwise) be different, we will adjust.
Brian

On Jun 10, 2013, at 12:32 PM, Lloyd McKenzie ‹lloyd@lmckenzie.com› wrote:

Technically, there's no semantic difference between sending an instance with null flavor of NI and sending an instance where the attribute/element is omitted. "NI" is the default interpretation for all missing data.
--------------------------------------
Lloyd McKenzie

Cecil: FIHR will be fine with PHIN VADS VASC; no need to worry at all

noreply@blogger.com (Barry Smith) — Sun, 26 May 2013 18:50:00 +0000

To: HL7 Vocabulary List

Cc: fhir <fhir@lists.hl7.org>
Subject: (FHIR) Value Set -> Code Set

At present, FHIR has a "value set" resource that is a simple representation of what the core principles defines a value set to be (In addition to this, it also allows a single resource that defines both a code system and a value set that includes the entire code system as an implementation convenience).

From an implementer perspective, "value set" is a completely opaque term. What's a value set- a set of values? Values of what...?

I propose to rename the FHIR ValueSet resource to "CodeSet" - this is actually what it defines - a set of codes that may be used in some context.

Grahame

On Sun, May 19, 2013 at 9:48 PM, <cecil.o.lynch@accenture.com> wrote:

Graheme,

I am opposed to this as I think it just adds confusion when the implementer looks at anything else such as PHIN VADS VASC, CTS2 or the core principles. At some point it is just better to say that the implementers need to learn the jargon rather than trying to change every other group to use yet another ambiguous term.

Cecil

The 'core principles' referred to are documented here.

FHIR: Let's Make Things Difficult Again

noreply@blogger.com (Barry Smith) — Fri, 10 May 2013 14:04:00 +0000

More interesting material on Eliot Muir's Interfaceware blog, in a thread on the topic of FIHR integration. Here Eliot proposes a strategy to counteract the looming redifficultization of FIHR, by opening up and democratizing the standards process and thus lowering the transaction costs in collaborating:

V3 and CDA proponents [along with proponents of other standards] could register resources and see who uses them. Over time natural selection will occur – people will gravitate to the resources that are most common and useful. … Some resources will be easier to do quality validation on. This will impact on the value that people see in those resources – for instance very large CDA documents are difficult to validate effectively so that may impact on the value that people see in them.

FHIR as currently conceived, in contrast, is to be, like other parts of HL7, centrally defined:

I’m just sitting on a group that is looking at device integration with FHIR. It’s a beautiful example of how problematic it is trying to make centrally defined standards to handle device data. There are so many different types of devices and the area is always changing. On the other side most of the EMRs don’t have the capability to display the data.

On why healthcare information standards need to be as simple as possible:

… the complexity and problems of the healthcare business itself provide more than enough craziness. Also crazy healthcare standards tend to help competing vendors that are willing to hold their nose and make specialized tools to deal with the niches they helped to create.

… Truth is that there are lots of incentives for different economic actors in healthcare to make interoperability and standards more complicated. The reality is that some times these create barriers to entry for competitors. What happens though is at some point a tipping point occurs when suddenly it becomes in everyone’s interest to make inter-operability easier rather than harder.

You have to look at the players realistically to try understand what their motivations are. Follow the money. One area that people make money in is being a consultant to government organizations in terms of helping them with developing interoperability with all the various programs they want to do. There are perverse incentives to make the standards a little complex and obtuse because it creates barriers to entry for competitors to do the work you want to do.

So good they abolished it twice:

Of course you can have too much of a good thing. One beautiful example was the NHS Spine. I had the joy of reading the spec on that one time to see if we could implement it. It was a nutty amalgam of LDAP, V3, ebXML combined into an impenetrable mess.

There were consulting companies associated with the development of that spec that had then developed products to implement connection to it. They were a little too effective; though in the sense I think in the end the NHS saw through it all and realized that it was too complicated to succeed. It was a classic example of ‘consultant capture’.

What would it take for FHIR to be successful:

... all participants have to able to only use the tools they are already comfortable with. One of the numerous reasons that V3 failed to get widespread market adoption was that it required a large investment in time to learn all the tools that were developed internally by HL7.

… An engineer in Mumbai that is working on a glucometer for medical device start up needs to be able to easily find or create a FHIR profile and be able to discuss it online without finding the equivalent of 3 months salary to come to WGM in order to find out they will need to come to six meetings and lobby like crazy before they even get a shot at contributing to the standard.

One of the things I noticed at the HL7 working group is how daunted a lot of the people were with even the current full tool set get going with FHIR. You have to install subversion and have the right version of Java. All of this stuff comes with a whole learning curve associated with it. Right now I can’t even really locate where the tools can be downloaded from the FHIR site.

For people outside of healthcare what HL7 does with your data seems quite crazy -- and it is!

noreply@blogger.com (Barry Smith) — Mon, 22 Apr 2013 00:25:00 +0000

Eliot Muir, responding to a comment to a recent post on his own Interfaceware blog, makes a number of interesting points on the difference between what you can do with a database, and what you are allowed to do with what he calls 'traditional HL7' :

The biggest thing about interfacing is that one way or another you want to get ‘random access’ to 100% of the data contained in any given application.
Your data – when you want, how you want it, where you want it.
For hospitals that have IT systems that only offer HL7 interfaces, the smartest way to get data in and out of those things is usually to ignore the HL7 interfaces and just query their databases directly. That’s extremely common for many health care providers I know of – it’s far less complicated. The problem is that the HL7 interfaces often only give access to a subset of the data contained in the database of any given application.
A second problem is the issue of coupling the data which is exposed to work flow events. i.e. admit, discharge, transfer etc. We’re so used to it in healthcare that it becomes second nature – we think that it’s normal to have to mirror data by always listening for events and faithfully recording the data – heaven forbid we should ever miss a message! Coupling data to events also leads to another headache with HL7 – so called ‘gap analysis’ where people pour over HL7 messages trying to determine for a given desired workflow sequence if a given message has the required data.
For people outside of healthcare this all seems quite crazy – and it is!
If I want to look up the demographics of a patient XYZ then I should just be able to query that information anytime I like. You can do that with a database – although that makes most application vendors squirm when you do that. Partly the reasons for that are legitimate technical concerns of violating the integrity of the application. Partly it’s for business reasons as alluded to above.
... I personally have no confidence that the IHE HL7 profiles will do anything of significance to improve actual integration outcomes in healthcare. It’s pretty crazy how much money has been put into IHE and how little it’s produced in terms of outcomes in real hospitals.
I think there are several reasons for this. One reason is that version 2.X HL7 has the above flaws. IHE HL7 doesn’t fix the flaws – instead it erects a shrine to the whole thing and puts a bow on it.
A second problem is that vendors cobble together all sorts of things with string and rubber bands to participate in the IHE connect-a-thons and then go back home and continue to sell the same systems they have been selling for years which don’t comply to the IHE profiles.
A third problem is that IHE only tells us about things that committees have gotten together and agreed upon. That tells us about the past – but it doesn’t tell us about the future. One of the privileges I have from running a company like INTERFACEWARE is that I get a fantastic view into the future of medical IT with respect to integration. I get to talk to dozens of start ups that are thinking of new imaginative ways to leverage the data we have already today to improve healthcare and reduce costs. For those startups RESTful APIs are a lot more convenient.
Incidentally in the US in the physician practice EMR space over 80% of integration is done using web based APIs – HL7 is more or less dead in that space already – it’s just a few older legacy applications that still use traditional HL7.

Why FHIR will burn CDA

noreply@blogger.com (Barry Smith) — Fri, 12 Apr 2013 21:59:00 +0000

An interesting post with this title from Eliot Muir a friend of this blog. (See, for example, "The Rise and Fall of the RIM" from 2011.)

As Eliot points out:

CDA/CCD documents amalgamate lots of data together. There are too many data points. That makes these documents extremely impractical for solving real world integration problems. They tend to be very brittle and difficult to accomodate changes. It’s one of many reasons why the cost associated with using CDA/CCDs for integration are so high with a low return on investment. I have seen the blood in the field.

FIHR, in contrast, has a much better design and is much more modular (A nice overview is here.) "The FHIR train has left the station. It’s picking up speed and no one, not I, not the HL7 organization, nor even Grahame Grieve who invented the thing can stop it. The concepts behind FHIR will have a life of their own. This train is going to be disruptive. If you run an organization in healthcare you need to know about it. Your only choice at this time is to get on the train, or step in front of it."

We remain sceptical. First, FIHR is owned by HL7. Second, FIHR is still based on the RIM -- which is what caused all the problems in the first place.

Implementing Obamacare? “Impossible endeavor”

noreply@blogger.com (Barry Smith) — Thu, 21 Mar 2013 20:27:00 +0000

By Michael Barone March 18, 2013 | 3:51 pm

Will the government be able to implement Obamacare smoothly? An “impossible endeavor,” writes a reader who describes himself as “83 years young, married to a beautiful lady for 65 years, with a 54-year career in technology starting with punch cards in the Navy, retired from three major corporations at the director level, last position was with EDS working on Y2K project.” He goes on to list some of the things he believes need to be done, which I quote with his permission. I don’t know enough about this to make a judgment myself, but I have noticed over the years that the federal government has had problems procuring information technology.

RESOURCE REQUIREMENTS

Technical

o Programmers

Depending on what languages are being used will require that skill set—I bet you a lot of that code is written in COBOL and the last time I have seen that skill set was when we worked on Y2K, and we had to bring them out of retirement.

o System Analyst

Strong ability to work with subject matter specialist to develop systems requirements and document for the programmers.

o Technical and Subject Matter Specialists

Writers to develop Standard Operating Procedures (SOP) for the end users (How many will that be???) and SOP’s for operations.

Computers

o Will we need various types of computer equipment in order to test and migrate to production? Problem is we must likely don’t have that computer capacity in order to test followed by migration to production

o Mainframes, Desktops and other devices that I am unaware of

o Will vendors have to get involved with hardware/software packages, etc?

o LANs

Interfaces (based on the GAO report-as follows)

o IRS

o HHS

o TREASURY

o INSURANCE COMPANIES

o SSA

o STATE EXCHANGES

o CORPORATIONS

o SMALL BUSINESS

o MEDICARE

Having identified the above organizations, corporations and Insurance companies will have requirements to modify their computer systems in addition to interfacing with their respective report-to organizations.

And unless I missed it, what about the Doctors having to provide information for Obamacare?

Finally, there is so much more, but I did want to give you a flavor of the magnitude of this impossible endeavor.

Human Action in the Healthcare Domain

noreply@blogger.com (Barry Smith) — Mon, 04 Mar 2013 17:10:00 +0000

An essay by Barry Smith, Lowell Vizenor and Werner Ceusters on the current state of the RIM, entitled

“Human Action in the Healthcare Domain: A Critical Analysis of HL7’s Reference Information Model”

has now been published in a Festschrift for Ingvar Johansson. The essay is available online here.

The Weight of the Baby After 5 Years

noreply@blogger.com (Barry Smith) — Fri, 22 Feb 2013 21:16:00 +0000

Fans of “The Weight of the Baby”, which is certainly the funniest of all postings to the HL7 Watch blog, may be interested to note that our loyal friend Anonymous has posted a new comment:

Anonymous said...

That is one mind boggling exchange. WC has the patience of a god. DR is a religious fanatic. DR is into some powerful mojo. Every HL7 consultant team should include a witch doctor.

2/22/2013 2:25 PM

American Cardiology Society Makes Ontological Errors

noreply@blogger.com (Barry Smith) — Tue, 29 Jan 2013 15:49:00 +0000

See new post by Bill Hogan to The Ontology Blog here.

An Ontologist's Guide to HL7

noreply@blogger.com (Barry Smith) — Wed, 16 Jan 2013 21:43:00 +0000

A talk under this heading was presented as part of the National Center for Biomedical Ontology seminar series. Slides and a recording of the talk are available here:

http://www.bioontology.org/ontologist's-guide-to-HL7

The RIM of Despond

noreply@blogger.com (Barry Smith) — Wed, 02 Jan 2013 21:39:00 +0000

Looking Back

In the more than 7 years since HL7 Watch was founded in 2005, we have drawn attention to a number of deep flaws in the structure of the RIM. Examples of such flaws are:

1. No coherent distinction between an observation and what it is on the side of the patient that has been observed.
See The Multiple Joys of HL7 V3

2. No coherent treatment of the relation between an act of observation and the statement, assertion, or datum (for instance a measurement result) that is the result of this act.
See The Weight of the Baby

3. No coherent distinction between an act and the record of an act.
See Still An Incoherent Standard

4. No coherent way within the framework of the RIM to track how concerns (for example diseases) in a single patient evolve with time.
See Still no coherent way to track concerns

5. No coherent way of distinguishing between condition (an enduring entity) and act (an event taking place at a time). (References to the 'condition of the patient' do indeed appear in HL7 standards documents, but the term 'condition' is nowhere defined – because it cannot be defined in conformance to the RIM.)
See Diseases as dependent continuants

5. No coherent distinction between intentional acts (for instance ordering, prescribing) and events in general (for instance accidental falls, events within the interior of the patient's body).
See HL7 and SNOMED CT

6. No coherent way of dealing with what the RIM calls 'effective time'.
See: Still confusion after 14 years

We have repeatedly pointed to the ways in which these flaws cause problems in learnability and teachability, and thus in usability and codability, of HL7 v3-based standards. We have also averted to the way in which these problems re-appear with each new generation of coders and business analysts charged with working with HL7 v3, as evidenced most recently by the email threads we cite below.

Where We Stand Today

HL7 v3 remains an incoherent standard. Indeed as we have shown in a recent paper (in press), matters are in this respect getting worse. The paper, which is entitled "Human Action in the Healthcare Domain", reviews the recent 'Release 4" of the RIM ballot document ISO/HL7 21731:2011(E), referred to in what follows as ISO RIM Release 4. This doctrine contains a series of welcome attempts on the part of the HL7 community to add clarity to their earlier publications, and it also contains a number of attempts to add ontology-like components to the HL7 structure. Unfortunately, however, these new additions do not replace the earlier, incoherent portions of the RIM specifications. Rather, they are simply added on to the existing formulations, with no attempt (as far as we can see) to secure any sort of logical consistency.

Because, astonishingly, the RIM's basic flaws have in this way been significantly magnified, the result will be further waves of instability in the v3 standards. Because the needed changes will be made by different specialist groups, new inconsistencies will arise, which will be resolved, where they are resolved at all, by ballot, rather than by logic. The prognosis for the future of HL7 is not good.

Matters are made still worse as a consequence of the inclusion of CDA/CCD – with their HL7 legacy elements – in the Meaningful Use standards. We can anticipate that the cries for help from within the HL7 and associated vendor communities will become even louder. First examples are already here:

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On
Behalf Of Kumara Prathipati
Sent: Mon 12/24/2012 10:40 PM
Subject: CCD DESIGN - VERY COMPLEX

Hello,

I was trying to understand allergies section CCD examples. It is very interesting the way CCD was designed to state "No known drug allergies". It is just mind boggling how complex and complicated the CCD design was.

Just to say "Pt has no known drug allergies' takes 25 lines of CCD. This tells us how inefficient this system has grown to be till now. [25] lines to tell 1 sentence "Patient has no drug allergies" (http://motorcycleguy.blogspot.com/2012/03/how-to-say-no-med-allergies-in.html).

... It is beyond my comprehension how this whole process ended up this complex. (looks like too late to change direction). If it needs a PhD to understand CCD, time to think again and commit to design a more simple system even if it takes a lot of effort..

Any one who is responsible to create a piece of software to generate CCD or import CCD has to spend his life time understanding. He has to attend many courses given by experts and spend thousands of dollars.

I looked at NCPODP XML representation of ERx which looks a 100 time more simple than CDD and any one can understand in a few hours (including myself who went thru it). Hats off to NCPDP experts who made it so easy any one can understand in less than 1 day.

Looks like the current CCD experts are unable (unwilling since it is too late) to make this a simple but equally effective system to meet 95% of requirements. Your are increasing the cost of creating the interoperability modules for EMR products and HIEs. Still the medical community is not using CCD on a wide scale which is a result of the complex system designed by experts. I do not believe it is not possible to design a system 1/2 as complex. I hear the same response "the requirements are complex and so the system is complex". I disagree with this statement ...

If CCD becomes very complex and expensive to implement, it will become a disaster in health care because the whole clincial data exchange depends on this.

I see endless discussions on the element . If it takes so much discussion, the elements are named vaguely and time to junk that element or rename it. Many elements have poor naming systems. It takes some times hours of Google search to understand the meaning of your CCD XML elements and attributes. XML is supposed to have self explanatory elements and attributes. This is missing in in many of elements.

Just to give an example of poor element/answer naming. When I see "code=ASERTION". Just makes no meaning at all to me. Concept is vaguely explained after extensive Google search.

... I am a practicing physician for 30 years and documenting allergy information for 30 years , almost daily. It's unbelievable frustration to digest your CCD manuals.

Kumara Prathipati MD

---

More examples of such cries for help (and associated general confusion) are provided in the email threads below, which are taken from the HL7 Strucdoc Digest of December 29, 2012. For the sake of readability, I have removed repetition and some digressions, and associated emails on a single topic in chronological order. Notes in yellow are from myself ([BS]) and Bill Hogan ([WH]).

Thread 1: Confusions regarding Observation.Code and Observation.Value

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On
Behalf Of Kumara Prathipati
Sent: Thursday, December 27, 2012 12:19 PM
Subject: Re: ALLERGY SECTION QUESTION

Brian,

To help many many thousands of coders and business analysts working in EHR, HIE companies we have to make this simple, simple and more simple.

I will explain like this

Observation/Code = question

Observation/Value = answer

some times answer does not require a question (then you can use nullflavor). This happens when answer is self explanatory.

Examples

Observation/code = manifestation

Observation/value = skin rash

Observation/Code = Temperature

Observation/Value = 99.8

Every observation must have /code and /value

Observation/Code = wound depth

Observation/value = 2.2 cm

Observation/Code = heart murmur

Observation/value = absent

I can [give] a 1,000 examples applicable in health care. I see no need to explain in 10 sentences but need to give 20 examples. Then no one has to attend courses to understand. Any one can implement CCD/CDA.

For heavens sake, at least give lot of examples with various clinical situations. EXISTING SYSTEM IS TOO COMPLEX, COMPLICATED, CONFUSING, FRUSTRATING ...

Kumara

---

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On
Behalf Of Brian Zvi Weiss
Sent: Thursday, December 27, 2012 4:44 PM
Subject: RE:



Kumara,



If I understand you correctly, the case you are making for the code/value of an observation being a question/answer with "code" always being present (or nullflavor),  is really more an argument about what SHOULD be the case in your view, rather than what IS the case. Correct?



The white paper from the Terminfo project talks to the role of code in the RIM as being "the action taken in making the observation".  It jumps through a lot of hoops to even justify "Body Weight" being a "code":



This example is not in line with strict interpretation of the formal RIM definition in which the Observation.code is the action taken to make the observation. However, it is a more familiar form in real-world clinical statements about many observations. A possible bridge between these two views is to regard the name of the property observed (i.e. "body weight") as implying the action to measure or observe that property.



So, the definition of "code" becomes "action of observing or the property observed" - and for situations where you don't have either of those, ASSERTION (not a nullflavor) is used for "code". 


[BS:] This tells us how deep is the confusion in HL7 circles as to what is meant by 'code'.



I'm not saying those were good decisions or arguing with you that we wouldn't be better off with what you recommended below. 



But I do think it's important that we keep separate:



1. "support" questions about how the standard is to be implemented (resolving ambiguity, establishing best practice, need for more examples, etc.).



2.  questions/challenges on the standard itself (that have to be addressed in future versions and other standards creation work)



I'm still not 100% clear if this listserv is the place for both of those agendas - I think it is.  Either way, it has to be clear to all when we are involved in a discussion about #1 and when about #2.



So, if we limit ourselves to #1 for a moment on this topic, I don't think your explanation works because it doesn't seem aligned with what the C-CDA spec requires.  The C-CDA spec is clear on where ASSERTION has to be used ... and other guidance on what values or value sets are legitimate for "code" in other templates.  ...



Brian



---



From: Mead Walker [mailto:dmead@comcast.net]

Sent: Thursday, December 27, 2012 19:36

Subject: RE: ALLERGY SECTION QUESTION



Hello Kumara,



I think your suggestion of illustrating points of possible confusion with examples is a great one.



However, it does seem one of your examples sits on the minority side of a much earlier debate about the use of code and value. Namely,





Observation/Code = heart murmur



Observation/value = absent





I think the more conventional approach would be:





Observation/Code = ASSERTION



Observation/value = heart murmur





By the way, I have always thought that one of the drivers behind this was

the desire to identify preferred code systems for observation code (LOINC)

and observation value (SNOMED and others (although hopefully only SNOMED to

some))



Mead


[BS] Compare the earlier debate in ontology circles as concerns an effective avenue for ensuring consistency as between 'Attribute' and 'Value', where some, for example, regard 'Color' as Attribute and 'Red' as Value, others regard 'Red' as Attribute, 'Dark' as Value. The solution proposed involves the imposition of a single hierarchy, whereby all values are seen as is_a children (subtypes) of the corresponding codes (values for codes at one level can be codes themselves for values at a lower level). Thus for example



 Color

  Red 

   Dark



Manifestation

 Skin rash manifestation

  Severe skin rash manifestation 



Temperature

        99.8 degree Celsius temperature 



Wound depth

        2.2 cm wound depth



Observation for potential heart murmur

 Observation for potential heart murmur with result: negative



For the general idea, see the discussion of the EQ method in Nicole L. Washington, Melissa A. Haendel, Christopher J. Mungall, Michael Ashburner, Monte Westerfield, and Suzanna E. Lewis, "Linking Human Diseases to Animal Models Using Ontology-Based Phenotype Annotation", PLoS Biolology 2009 November; 7(11): e1000247. http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2774506/



----



Thread 2: Assertions and Observations



From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On

Behalf Of Lisa Nelson

Sent: Friday, December 28, 2012 01:52

Subject: RE: 

Brian,



I thank you for bringing up both this issue about the use of "Assertion" in the code element of an observation and the syntactical issue of the outer Problem Concern Act that can group several Problem Observations into a single Problem Concern.



I have been very concerned about the use of "Assertion" in the observation templates you have identified and several others too. (Check out some of the Problem Observation examples on page 442 of the C-CDA IG. They show the use of "Assertion" as the observation/code/@code even though the value set established for the code element does not include "Assertion" as one of the value set codes.)  Also, my experience testing CDA Documents for Connectathon has revealed that vendors do not adequately represent Problem Concerns in the narrative text of a Problem Section.  They are revealing a "structured representation" of the machine readable entries which does not show, in a humanly readable way, the relationship of the outer Problem Concern which wraps the Problem Observations.  Vendors just aren't getting this (in my opinion). 



I think it is very important to examine the impact and rationale for using "Assertion" and further delve into the Problem Concern Act and what it's use implies for implementations. Now that we are beginning to get some real implementation experience, I think we should step back and see if we truly understand the impact of our earlier design choices, in order to confirm if they all still make sense or not.



... I think it is time we clearly understand what this decision implies for the practical use cases of the data.  I would not be at all surprised if something that we thought made sense a couple of years ago, turns out not to be a good idea, now that we see the implications for implementation.  I think this topic about the use of assertion and the other topic about the use of the outer Concern Act need to be carefully scrutinized to make sure our implementation guidance makes sense in light of what we are envisioning for quality measures which are highly dependent on being able to identify problems in a patient's record. Now that we have  a clearer picture about how Quality Measures are specified (HQMF) and how patient-level quality documents are created (QRDA), I think we need to make sure that our implementation guidance for recording problems, lines up with the envisioned future uses of the information. ...



Regards,



Lisa



----



From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On

Behalf Of Brian Zvi Weiss

Sent: Friday, December 28, 2012 5:05 AM

Subject: Considering Changes in ASSERTION and nesting of Problem and Allergy Concern Acts



Thanks, Lisa.  ... I think we have to be very careful here when it comes to how we approach evolving the standard, now that it is baked into MU2 and the "train has left the station" on that.



In my thread yesterday with Bob re. my expectations for active "disambiguation"  of the spec by HL7, my assumption was that we were looking to create additional constraints that would further refine the ones we already have in order  to eliminate ambiguity in the implementation of those existing constraints - but without changing the existing constraints. 



But here you are (as Kumara was earlier) referring to potentially substantively changing the spec.  I'm not arguing the correctness of your recommendations - they make sense.  But as in my earlier comments to Kumara, I think we need to be very careful to keep separate the issue of "how the spec should change/evolve" from "support infrastructure".  Really there are three categories here:



1)  Support infrastructure for answering questions that don't have implications for changes in the spec



2) Resolution of ambiguities via additional constraints (what Josh terms "best practices") being added to the spec (initially as "best practice guidance" and then working their way into the next release of the spec)



3) Evolution of the spec itself to change how things are done (creating new constraints that contradict the previous ones)



... In #1, I think the key issue is to what level HL7 wants to be involved here, the business model for funding it (e.g. membership only), the resulting SLA and infrastructure, etc.



 In #2, I think the key issues are:



A.  What is the right way to handle the process in both an authoritative and timely way, given that the cycle for full revisions of a spec and all the associated process for attaining consensus via balloting, etc. is too slow and we can't leave so many fundamental ambiguities out there for the market to sort out one pairwise integration at a time.



B. What is the commitment level of HL7 to focusing on this agenda rather than just "moving on" to the next version of the spec, other standards, etc. and the infrastructure for making it work



In #3 I think the key issue is what the rules of the road are once the train has left the station, as I noted above.  MU2 rules are working their way into certification testing infrastructure and are actively being worked on by vendors who have high levels of pressure and urgency to get their products "MU2 certified" quickly.  The implications of changing up the rules on them midstream is worrying. 



... Of course at the end of the day, as you noted, we shouldn't have to live forever with a significant mistake (from a practical implementation perspective) once we've identified it.  Just saying it's tougher to navigate the whole issue of backwards compatibility when a particular release takes on a life of its own as part of something like MU.  I think it would be a something of a nightmare if the latest C-CDA spec was not consistent with what was being tested (or planned to be tested soon) for the latest (or upcoming) MU certification round. 



So I would caution us re. the "enemy of 'good enough' being 'perfect' ".  As long as we disambiguate and provide enough examples, the market will manage through the stuff that has us now scratching our head and asking "how did we end up with this strange construct".  Not ideal, but probably not tragic - as long as there is a clear, single, right way to create/interpret the information and it is possible to get in the data into the document.  The time may have passed for "doing it better".



---



From: Lisa Nelson [mailto:LisaRNelson@cox.net]

Sent: Friday, December 28, 2012 6:08 AM

Subject: RE: Considering Changes in ASSERTION and nesting of Problem and

Allergy Concern Acts



Brian,



... I agree with the sentiment that you have expressed. We need to find a way to work on this plane while we are flying it.  ...



I believe we can do it.  We need to do the disambiguation, develop the examples, and then release clarified guidance (which could involve adding some additional constraints) in a way that doesn't break everything we have already put in place.  I think that template versioning plays a key role in developing the ability to do this, which is why I'm focusing there first. Once we have clearly defined how to do versioning, then we will have the mechanism to release, for example, a new Problem Observation  or Problem Concern Act template which is a new version of the existing template but includes the revisions which we determine will add the needed clarity without breaking our prior constraint assumptions.  It is a tricky puzzle to solve, but I'm certain it can be done.  ...



Lisa



Lisa R. Nelson, MS, MBA | Consultant | Life Over Time Solutons | cell:

401.219.1165 | Westerly, RI | LisaRNelson@cox.net



---



From: owner-vocab@lists.hl7.org [mailto:owner-vocab@lists.hl7.org] On Behalf Of W. Ted Klein

Sent: Friday, December 28, 2012 8:54 AM

Subject: Re: HITSP value set stewardship



... I am concerned because questions about Quality Measures keep coming up around the vocabulary, and I don't know of any authoritative sources of truth for the sets of codes to be used, and in some cases even the identifier of the value set to be used.  This whole thing resembles some kind of hot potato that no one wants to hold on to for very long.



Ted



----



From James T. Case

James T. Case MS, DVM, PhD, FHL7, FACMI

Health Program Specialist, SNOMED CT

National Library of Medicine, National Institutes of Health

On Dec 28, 2012, at 10:35 AM, "Case, James (NIH/NLM) [E]" wrote:



Ted,



As far as I am aware, all of the value sets that were identified for the approved eMeasures for MU stage 2 are available from VSAC (https://vsac.nlm.nih.gov).  You would be well advised to point those that have vocabulary questions to that site.  The VSAC is the â€œsource of truthâ€ for all of these measure value sets.



Jim



---



From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On

Behalf Of Brian Zvi Weiss

Sent: Thursday, December 27, 2012 12:41 PM

Subject: RE: ALLERGY SECTION QUESTION



Josh,



...  Sounds pretty compelling - would be curious if anyone on this list wants to make the case for a counter-argument that multiple observations within a concern act (allergies and/or problems) should be used?



Does the best practice place any value on the concern act at all?   As per Gaby's note, the effectiveTime data range in the concern act adds no value if C-CDA says it has to be the same as that in the observation (BTW, where does it say that? I tried to find that in the C-CDA IG but didn't see it?). The concern act status doesn't seem to add value, only confusion if it contradicts the observation status. 



So, is the best practice just to consider the concern act "wrapper overhead" and create it to spec when creating the C-CDA and ignore it on interpretation of a received C-CDA?



Brian



---



Thread 3: Continuing Confusions about Effective Time



From: Brian Zvi Weiss [mailto:brianzviweiss@gmail.com]

Sent: Thursday, December 27, 2012 1:06 PM

Subject: RE: ALLERGY SECTION QUESTION



... So, it sounds like there isn't consensus on the best practice here that Josh is recommending (limiting concern to a single observation).  Various questions in my mind (like how the example you gave would work given the limitation Gaby and Josh noted on the effectiveTime in the concern and the observations - though also not sure where in the IG it says that) but I'm out of my depth here.  My boundary ends with "understanding what is in the standard" (trying to do that) not discussing "what should be in the standard".  So, I'll leave that to you, Josh, and others. 



As always, I would just encourage us to not leave this hanging and try to come to some kind of authoritative guidance.  This is another example of  where the spec alone isn't enough (as "the whole problem list in a single concern" is syntactically valid, there is debate on the best practice recommendation, etc.).  I'm happy to assist in writing up the conclusions. But can't help in deciding what that conclusion should be.



Brian



---



From: Bob Dolin [mailto:bob.dolin@lantanagroup.com]

Sent: Thursday, December 27, 2012 22:49

Subject: RE: ALLERGY SECTION QUESTION



Hi Brian,



... Think of the concern act as corresponding to an item on a problem list. Pretty much every EHR I've seen allows you to make sequential updates to a problem - e.g. today you might call it "chest pain", next week, after further study, you might update it to "esophagitis". I acknowledge that more guidance would help.



To Josh's point, the rationale for multiple observations in a Concern wasn't to allow you to put the whole problem list in a single Concern, but rather to allow you to track the course of a problem over time.



Bob



---



From: Bob Dolin [mailto:bob.dolin@lantanagroup.com]

Sent: Thursday, December 27, 2012 23:26

Subject: RE: ALLERGY SECTION QUESTION



Hi Brian,



Where a concern has multiple observations - consider an EHR, where a clinician updates an item on the problem list, then updates that item again at a later date. Typically, the most recent observation would be displayed by the EHR, with the other observations retained for historic reference.



As for "authoritative guidance" - this is tricky. Imagine for instance, we create a standard that has an ambiguity (I interpret it one way, you interpret it another way). We then issue "authoritative guidance" that says to do it the way you've interpreted it. Would you then find instances based on the way I interpret it to be non-conformant? Historically, Structured Documents has issued "internal working documents" [http://wiki.hl7.org/index.php?title=Structured_Documents_Internal_Working_Documents]. ...



Bob



---



Subject: effectiveTime in Problem Concern Act and nested Problem Observations (and effectiveTime in Allergy Concern Act)

From: "Brian Zvi Weiss" Date: Fri, 28 Dec 2012 10:18:55 +0200



Bob,



Where a concern has multiple observations - consider an EHR, where a clinician updates an item on the problem list, then updates that item again at a later date. Typically, the most recent observation would be displayed by the EHR, with the other observations retained for historic reference.



Can you explain how effectiveTime should be used in the problem concern act you described (item on the problem list updated several times and the other observations retained for historic reference)?  Ideal would be an example C-CDA snippet demonstrating this.



[WH]  Here we see ongoing and persistent confusion about what effectiveTime is for.

From what Josh and Gaby wrote there seems to be an understanding that the effectiveTime should be the same for all observations in the same act and for the act itself.  I can't yet figure out where it says this in the C-CDA spec - I think Josh indicated this was implied by the guidance to use "onset date" for the lower bound of the effectiveTime and Gaby seemed to suggest it was an explicit requirement that the act and observation effectiveTime match.  All I saw for Problems was the following in the Problem Act:



The effectiveTime element records the starting and ending times during which the concern was active on the Problem List.



And the following for the problem observation:



This field [low] represents the onset date.  This field [high] represents the resolution date.  If the problem is known to be resolved, but the date of resolution is not known, then the high element SHALL be present, and the nullFlavor attribute SHALL be set to 'UNK'. Therefore, the existence of a high element within a problem does indicate that the problem has been resolved.



But assuming Gaby and Josh are correct, those constraints they indicate don't seem consistent with the scenario you are describing whereby the whole point of having multiple observations in an act is to track the historical evolution of the concern as the observations change? 



I'm trying to get to the bottom of this. a concrete example would help out a lot here!



Once that is clear, I'd also like to understand the difference in how effectiveTime works in Problems and in Allergies.  The guidance on the Allergy Concern Act is:



If statusCode="active" Active, then effectiveTime SHALL contain [1..1] low.

If statusCode="completed" Completed, then effectiveTime SHALL contain [1..1]

high



and there is no effectiveTime on the allergy problem observation(s) contained inside the allergy concern act.



Brian


[BS] From the ISO RIM Release 4 document we learn that



Act.effectiveTime =Def. The clinically or operationally relevant time of an act, exclusive of administrative activity.



In the associated Usage Notes we are told that 'The effectiveTime is also known as ... the "biologically relevant time" (HL7 v2.x).' The first example provided is then: 'For clinical Observations, the effectiveTime is the time at which the observation holds (is effective) for the patient.'  Unfortunately, the effectiveTime in this example is not the 'relevant time of an act', rather it is the relevant time of a condition on the side of the patient. For  a clinical observation such as 'staph aureus infection detected' the effectiveTime (as "biologically relevant time") would start when the corresponding condition first begins to exist in the patient. But because the RIM has no place for conditions in the patient, but rather only for observations of conditions, the RIM has no means to formulate this understanding clearly. The result are the repeated flare-ups on HL7 discussion lists where ever new parties complain that they do not understand what is meant by 'effectiveTime'.



As the reader can easily ascertain, the further examples of correct usage of 'effectiveTime' in the ISO Release 4 document do not, unfortunately, resolve the confusion.


---



From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On

Behalf Of Brian Zvi Weiss

Sent: Friday, December 28, 2012 10:19

Subject: effectiveTime in Problem Concern Act and nested Problem

Observations (and effectiveTime in Allergy Concern Act)



Bob,



Where a concern has multiple observations - consider an EHR, where a clinician updates an item on the problem list, then updates that item again at a later date. Typically, the most recent observation would be displayed by the EHR, with the other observations retained for historic reference.



Can you explain how effectiveTime should be used in the problem concern act you described (item on the problem list updated several times and the other observations retained for historic reference)?  Ideal would be an example C-CDA snippet demonstrating this.



---



Subject: statusCode in Problem Concern Act and nested Problem Observations (and Allergy Concern Act / Observation)

From: "Brian Zvi Weiss" Date: Fri, 28 Dec 2012 11:26:56 +0200



Bob,



....  In this mail I want to focus on status values.  Again, let's start with Problems and then we'll go to Allergies.



The Problem Concern Act has a status code where the value set is listed as 2.16.840.1.113883.11.20.9.19 (ProblemAct statusCode) - which means the following choice of values (as per Table 124: ProblemAct statusCode Value Set): active, suspended, aborted, completed.



The Problem Observation status code comes from the same code system as above

(2.16.840.1.113883.5.14 HL7 ActStatus) and is set to a fixed value of "completed".  Nested inside the Problem Observation is (optionally, 0..1) a single Problem Status, whose value attribute comes from the value set HITSPProblemStatus 2.16.840.1.113883.3.88.12.80.68 which is part of SNOMED.  The values there are: active, inactive, resolved.



So.



1)      What is the precise meaning of the status in the status code of the Concern Act?



2)      What is the precise meaning of the status in the Problem Status value inside the Problem Observation(s) inside the Concern Act?



3)      What rules, if any, govern the relationship between the status of the Act and that of the Observation it contains (in the case of a single Observation)?



4)      What rules, if any, govern the relationship between the status in the Problem Status value inside the Problem Observations when there are multiple Observations inside a single Concern Act?  Does the case of multiple Observations change the previous answer in #3 re. relationship of status in Concern Act and status in Observations (plural)?



5)      How are status changes of an Observation managed within a Concern Act?  Are you supposed to have multiple Observations indicating the evolution of the Observation within the Concern, or just replace status of the Observation with the new status?



In terms of Allergies, the status codes match up with Problems - the concern act uses a status from 2.16.840.1.113883.11.20.9.19 (ProblemAct statusCode) and the Allergy Intolerance Observation has nested in it (optionally, [0..1]) an Allergy Status Observation whose value attribute comes from 2.16.840.1.113883.3.88.12.80.68 (HITSPProblemStatus).  So, hopefully the answers above are directly applicable to Allergy Concerns/Observations as well.



Brian



----



Subject: RE: strucdoc digest: December 28, 2012

From: William Goossen Date: Sat, 29 Dec 2012 23:32:55 +0100



Brian,



The concern act would get a time for its creation. An observation of an onset would get its own time, which could be different from the concern, onset can be of earlier date. It is well explained in the care provision domain care structures topic. Unfortunately you will have to go back for the details to Sept 2009 dstu ballot



Vriendelijke groet,



William Goossen



---

CDISC Discovers "Concept Maps"

noreply@blogger.com (Barry Smith) — Thu, 11 Oct 2012 20:50:00 +0000

My attention was drawn to interesting developments on the CDISC front by the following, from Kerstin Forsberg of AstraZeneca:

Checkout "mind maps" slide 13-15, 27 for#CDISC SHARE http://ow.ly/dHfy5 < Then have a look at http://code.google.com/p/ogms/

The CDISC slide deck she refers to does indeed contain interesting representations of, for example, deep brain simulation as a treatment of Parkinson's Disease (slide 14):

But the question arises: how are the nodes and edges in such a graph to be interpreted. On slide 14 we are told that:

[the b]asic building block is a “concept” which is a piece of clinical information. Examples include:
–systolic blood pressure observation
–systolic blood pressure result
–sodium concentration in plasma observation
–subject's birth weight result
–study subject
–visit
Each of these concepts has component parts (including what we would conventionally call variables)

The 'treatment' and 'Parkinson's Disease' nodes in the above, therefore, represent pieces of clinical information. Given the context in which slide 14 appears, I assume that these are pieces of clinical information about some given patient. But how, on this basis, can we provide a coherent interpretation of the edges on the graph. How, for example, can 'implanted in' be understand as linking a piece of information about this patient's brain with a piece of information about some lead?

Questions such as this were addressed (and I had optimistically assumed) put to rest already in 2006. The answer to such questions is that there is no coherent interpretation of the edges in a graph of the sort displayed if the graph is taken to be about relations between concepts. The Ontology for General Medical Science (OGMS) shows, I believe, how to create and interpret such graphs in a coherent fashion -- paying careful attention to the distinction between portions of reality on the side of the patient -- for example actions of treating, brains, neurostimulators -- and the types of which these portions of reality are instances.

OGMS is built on the basis of the assumption that each term and each relation used in the graph representation of a clinical encounter needs to be defined in a logical way. Only thus can the information contained in the graph serve computational inference. It is sad that, after so many years, important groups investing considerable efforts in healthcare informatics have still not apprehended the need for such definitions.

Update: October 18, 2012

XML4Pharma submitted the following query:

Not being a specialist in ontologies, I need some more explanation.
Do you mean that for each node, the edges (predicates I presume in the RDF context) cannot be defined in a unique way, i.e. there is an infinite number of possibilities for each edge to be named? E.g.
1. What one person defines as "is part of" can be defined by another as "is component of". Is that the problem?
2. Or should there for each pair of nodes be only a distinct set of predicates available?
3. Or do you mean that to assign a name to an edge, some systematic rules must be followed?

Ad 1. Currently, the standards defined for RDF, as for OWL (as for XML), place very few restrictions on what relations and what sorts of relations can be used to link nodes in an ontology graph, and they place no restrictions at all on what such relations should be called. This leads to the same sort of chaos as would be created if diferent airlines used different standards for representing time in publishing their schedules. In "Relations in Biomedical Ontology" we suggested a solution to this problem, and this solution has been applied and refined within the framework of the OBO Foundry.

Ad 2. I believe that, for each pair of nodes, only a small set of relations will be meaningfully applicable.

Ad 3. As stated under 1., we need standards which will ensure that the same relations receive the same names on all occasions of use. OGMS is an attempt to set forth the needed standards for annotating data relating to clinical encounters.

HL7 To Make Intellectual Property Available at No Cost

noreply@blogger.com (Barry Smith) — Thu, 06 Sep 2012 14:13:00 +0000

On Tuesday, HL7 International announced that, beginning in 2013, it will make most of its intellectual property, including standards, available at no cost under licensing agreements.

For more details, see HealthcareInformatics, 9/4, which refers to:

a produced statement [from] John Halamka, M.D., MS, CIO at the Beth Israel Deaconess Medical Center and Professor of Medicine at Harvard Medical School: “This announcement is the most significant standards development in the past decade ... It ensures that every stakeholder will have ready access to the content standards they need for Meaningful Use.”

This statement may, however, be a mite misleading. As I understand matters, those wishing to satisfy Meaningful Use criteria can use CCR from ASTM instead of CCD from the HL7 shop (and even CCD is now a chimera of CCR/HL7 CDA). HL7 seems to have been unresponsive to actual needs, to the degree that it was surprised and embarrassed by CCR.

Re-fur-bish (verb): To bish, again, with fur

noreply@blogger.com (Barry Smith) — Fri, 03 Aug 2012 17:49:00 +0000

Rene Spronk, in his new proposal to "Renovate HL7 version 3" recognizes that HL7 v3 has failed. As he points out, almost all implementations of v3 today are not in keeping with the original intentions of the v3 developers. “I've been working on the HL7 version 3 standard for about 10 years - but based on experiences gained during consultancy projects with implementers, and based on experiences of implementers …, I see no other way forward for HL7 v3 then to embark on a renovation project.”

'Renovation', according to the dictionary means: to restore to an earlier, better state. For Rene, to renovate means: to optimize "for the kind of HL7 v3 implementations that we actually see in use today". He proposes three alternative paths to such renovation:

Proposal 1. involves adding a new layer of "re-usable elements" to HL7 v3 and "getting rid of the 100s of different R-MIMs".

But where will these new re-usable elements come from? And who, given the failures thus far, will trust a methodology based on the RIM to yield elements which will actually be reused?

More interesting are the proposed second and third alternative paths:

Proposal 2. is to renovate HL7 v3 by "moving everything to CDA R3, and to cease development related to HL7 v3 messaging."

Propose 3. is to renovate by "moving everything to FIHR [= Fast Healthcare Interoperability Resources] and to cease development of HL7 v3".

Thus in both cases ‘renovation’ in the sense of: abandonment.

Everything in the FHIR (pronounced ‘Fire’) is, to be sure, required to have a ‘mapping to the RIM’. But this, we presume, is simply for reasons of nostalgia ... for earlier, better times.

Death by HIPAA

noreply@blogger.com (Barry Smith) — Sun, 24 Jun 2012 15:59:00 +0000

From INFO/LAWhttp://blogs.law.harvard.edu/infolaw/2012/06/22/death-by-hipaa/:

Vioxx, the non-steroidal anti-inflammatory drug once prescribed for arthritis, was on the market for over five years before it was withdrawn from the market in 2004. Though a group of small-scale studies had found a correlation between Vioxx and increased risk of heart attack, the FDA did not have convincing evidence until it completed its own analysis of 1.4 million Kaiser Permanente HMO members. By the time Vioxx was pulled, it had caused between 88,000 and 139,000 unnecessary heart attacks, and27,000-55,000 avoidable deaths.

The Vioxx debacle is a haunting illustration of the importance of large-scale data research….If researchers had had access to 7 million longitudinal patient record, a statistically significant relationship between Vioxx and heart attack would have been revealed in under three years. If researchers had had access to 100 million longitudinal patient records, the relationship would have been discovered in just three months….

HL7 RIM has done its job on HL7 V3. Now it’s time to undermine the V2 standard

noreply@blogger.com (Barry Smith) — Mon, 12 Mar 2012 15:32:00 +0000

I am noticing changes introduced in V2.7 of the HL7 standard – described by one Asian HL7 expert as ‘subtle, insidious and dangerous’ – which consist in the insertion of failed RIM strategies into the newer versions of V2.x. Simple, usable standards are thereby becoming progressively more complex. Mood Codes, for example, the source of so much of what is impenetrable in HL7 V3, are now being reverse-engineered into V2.7, even while the V2.7 documentation acknowledges that At this time, there are no documented use cases for this field. And the CWE ('coded with exceptions') data type, which in V2.6 had 9 components, has 22 components in V2.7 along with multiple new subcomponents.
While, therefore, it is being widely acknowledged on the one hand that HL7 V3 has failed, V3's defenders are on the other hand injecting into V2.x some of the very components of the V3 approach which had made it non-viable for messaging.

On Mood Codes in V2.7

For examples of insertions of Mood Codes in V2.7, see chapter 2, section 2.8.1 and Table 0725, and chapter 7, section 7.4.2 (OBX - component 22 - CNE - Mood code):

Definition: This field identifies the actuality of the observation (e.g., intent, request, promise, event). Refer to HL7 Table 0725 - Mood Codes for valid values. This field may only be used with new trigger events and new messages from v2.6 onward.

Note: OBX-22 Mood Code was introduced in v2.6 to support Patient Care messaging concepts and constructs. At this time, there are no documented use cases for this field in the context messages as described in this chapter. This statement does not preclude the use of OBX-22, but implementers should exercise caution in using this field outside of the Patient Care context until appropriate use cases are established. While a similar note exists for OBX-21 Observation Instance Identifier, particular care should be taken with OBX-22 as this could modify the intent of the segment/message and create backward compatibility problems.

5. V 2.7 - Chap 11.2.1.3 "The use of HL7 Version 2.x in clinical messaging has involved the use of segments in ways for which they were not originally intended, as well as the development of the REL segment to express important relationships between clinical data components. Such use has also necessitated the introduction of mood codes to allow for the richer representation of intent, purpose, timing, and other event contingencies that such concepts required.

On CWE (coded with exceptions) in V2.6 and V2.7
In V2.6, CWE had 9 components as follows:

SEQ	LEN	DT	OPT	TBL#	COMPONENT NAME	SEC.REF.
1	20	ST	O		Identifier	2.A.74
2	199	ST	O		Text	2.A.74
3	20	ID	O	0396	Name of Coding System	2.A.35
4	20	ST	O		Alternate Identifier	2.A.74
5	199	ST	O		Alternate Text	2.A.74
6	20	ID	O	0396	Name of Alternate Coding System	2.A.35
7	10	ST	C		Coding System Version ID	2.A.74
8	10	ST	O		Alternate Coding System Version ID	2.A.74
9	199	ST	O		Original Text	2.A.74

In V2.7, however, this has been expanded to 22 components, which are made even more complicated by the introduction of Value Sets and OIDs (unique object identifiers).

As of v2.7 a third tuple, formerly known as triplet, has been added to the CWE data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components.

So each set in V2.6 receives an additional OID (SEQ 14) and a value set OID (SEQ 15) . And this set of 6 is repeated 3 times.

HL7 Component Table - CWE – Coded with Exceptions

SEQ	LEN	C.LEN	DT	OPT	TBL#	COMPONENT NAME
1		20=	ST	O		Identifier
2		199#	ST	O		Text
3	1..12		ID	C	0396	Name of Coding System
4		20=	ST	O		Alternate Identifier
5		199#	ST	O		Alternate Text
6	1..12		ID	C	0396	Name of Alternate Coding System
7		10=	ST	C		Coding System Version ID
8		10=	ST	O		Alternate Coding System Version ID
9		199#	ST	O		Original Text
10		20=	ST	O		Second Alternate Identifier
11		199#	ST	O		Second Alternate Text
12	1..12		ID	C	0396	Name of Second Alternate Coding System
13		10=	ST	O		Second Alternate Coding System Version ID
14		199=	ST	C		Coding System OID
15		199=	ST	O		Value Set OID
16		8=	DTM	C		Value Set Version ID
17		199=	ST	C		Alternate Coding System OID
18		199=	ST	O		Alternate Value Set OID
19		8=	DTM	C		Alternate Value Set Version ID
20		199=	ST	C		Second Alternate Coding System OID
21		199=	ST	O		Second Alternate Value Set OID
22		8=	DTM	C		Second Alternate Value Set Version ID