Administrative Gender Code System: The Never Ending Story

*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

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

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

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

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

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

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?

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

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

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

To: HL7 Vocabulary List

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

hi

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.