Assertion pattern in FHIR

=Original Title: Binding Relationship Types to SNOMED CT Relationship Types

Howell, Christopher Christopher.Howell@agfa.com via lists.hl7.org

Apr 18

to fhir I have a question that I have tried to explain below. I don't know if all that explanation is needed. I will try to be succinct first, then if my question is clear, you can ignore the explanation of how the question arises.

To summarize: Can a specified terminology binding bind elements to SNOMED CT relationship(attribute) codes? Codes like |PROCEDURE SITE DIRECT| and |PROCEDURE SITE INDIRECT|. These would be used in name, value pairs with the name is bound to SNOMED attribute codes.

To focus a little: Can you specify something like <relatedItem><type/><target/></relatedItem> where relatedItem.type has a terminology binding to SNOMED attribute(relationship) codes?

How this question came up:

I am investigating the use of FHIR resources in a system which works with clinical findings and procedure descriptions as SNOMED CT expressions.

I want to explore the question: Can findings and procedures expressed in SNOMED be mapped, reversibly, to FHIR resources?

In my case, I am looking at using and extending Procedure, Condition and Observation resources.

For example, a procedure may be described by a SNOMED concept P with qualifying and refining relationships with other concepts given by triples (P, R1, C1), (P, R2, C2), (P, R3, C3)... The R's are attributes.

Given P, a SNOMED CT procedure concept code, allowable types for Ri and Ci are specified in the SNOMED Concept Model.

So, is there a mapping of this set of triples, constrained by the SNOMED concept model for procedures, to a Procedure resource?

To start, the Procedure.type can contain P as a CodeableConcept with a SNOMED Procedure code.

Because both systems have been designed to model similar realities, there may be elements of the Procedure resource that corresponds to allowable SNOMED Concept Model attributes for procedures.

<bodySite> in <Procedure> represents something similar to SNOMED |PROCEDURE SITE|. But there are more specific relationships in SNOMED CT. These are |PROCEDURE SITE DIRECT| and |PROCEDURE SITE INDIRECT|.

There seems to be the intention for these more specific relationships to be handled in FHIR somehow. The Procedure.bodySite definition has the comment "To Do Is this approach or target site?" (This comment seems to relate to my question.)

There are lots more SNOMED procedure concept model relationships which have no corresponding elements in FHIR. Relationships to devices used in a procedure, and how used, for example. It would seem to go against the intent of FHIR to add elements for these relationships to be in the definition of the Procedure resource.

If there is no Procedure element that corresponds to the SNOMED relationship then it might be that the <relatedItem> element could be used. But the relationship types that can be used are limited by the terminology binding to "caused by" or "because of".

Is there now or could there be something like a <relatedItem><type/><target/></relatedItem> element where the terminology binding for the <type> element could bind to SNOMED CT attribute codes?

Or can a profile define an an extension to handle (name,value) pairs where name binds to SNOMED CT attribute codes?

A useless approach to the mapping question would be to store the conjunction of all SNOMED triples as a single SNOMED expression in the Procedure.type element. This is a reversible mapping.

---

Grahame Grieve grahame@healthintersections.com.au via lists.hl7.org

Apr 18

to fhir, hl7_pat, Christopher hi

you have asked many searching questions, and I will see if I can provide a coherent answer.

First: the Procedure.type can contain a snomed expression, and this is allowed to be as complicated as you'd like. Though it's certainly worth keeping in mind that systems that can handle expressions are as yet uncommon. The FHIR instance validators will validate the syntax of the expression, but not the semantics (I'll get there eventually). The same applies to Condition and Observation.

As you point out, common Snomed qualifiers overlap with other elements in the resource. Note this comment on Observation.bodySite: "Only used if not implicit in code found in Observation.name" Cause the bodysite - and other elements - are commonly pre-coordinated in the Observation.code - whether it's an expression or not. And the same thing would apply to Procedure.code and Condition.code. I actually thought that we made that same statement throughout Procedure and Condition, but I see that we don't. (I can see that there'll be a series of suggested improvements at the end of this thread, and that's the first - clarify about this).

In the absence of that statement about Procedure and Condition, I guess the nearest-to-right thing for you to do would be to put the snomed codes for bodySite etc in the element, and the others in the expression. Or put them in both places.

As to whether the bodySite is approach or target, I don't know why that's a todo - my take on the definition is that it's intended to be the target site (procedure site - direct), but the definition definitely needs improving (and possibly the model - if you can specify more than one body site, why? We'd have to review what people commonly record about procedures). I had hoped that we would map elements like this to Snomed, so that the qualifier - if there is one - is known with certainty. However that didn't happen for the DSTU - and honestly, Snomed has very sparse coverage of the things we have elements for, which is why it didn't happen.

As defined and structured, the related Item is not suitable for your use. You could go for an extension - that would be allowed and viable - or you could put the codes in an expression. I don't know whether your trading partners can deal with snomed expressions - that might dictate which approach to use.

It might be that we should add more elements to Procedure and/or Condition. If you're using them, it wouldn't hurt to review them - so why don't you post a list of the relationships that you have, and we can see how many other systems have the same data elements

Grahame

cc: patient care since they maintain Procedure and Condition

---

Christopher Howell Christopher.Howell@agfa.com via lists.hl7.org

Apr 21

to grahameg, grahame, fhir, hl7_pat I thank Grahame for his comments.

My question is at this time theoretical. So I am sorry I can't give you a list of SNOMED CT attributes we will be using. We have no external trading partners yet. Evaluating FHIR, I considered SNOMED CT Clinical Finding and Procedure attributes used in expressions allowed by the SNOMED Concept Model, and looked for corresponding elements in FHIR Procedure, Observation, and Condition resources.

At a glance, SNOMED expressions can be too detailed for explicit representation as FHIR resources. (and vice versa) This is probably a good thing.

Where there is overlap, as in bodySite, it seemed that some confusion was possible.

Grahame points out the comment on Observation.bodySite, "Only used if not implicit in code found in Observation.name"

So at least some SNOMED detail, like bodySite, can be and should be hidden in Procedure.type, Condition.code, and Observation.name, where SNOMED expressions can be stored. Technically, I am talking about clinical kernel expressions, not expressions with context, like family history and negation, which apply to clinical finding and procedure expressions, changing their meaning.

I wonder how far that goes. It simplifies a reversible mapping between SNOMED and FHIR if SNOMED expressions are preserved and the information they convey is not duplicated in other elements of the resource. But as Grahame says, systems that can handle expressions are uncommon.

There are not many required elements in FHIR. And for the optional elements, the "Only used if not implicit in code" constraint suggests that at least some of the information encoded in the SNOMED expression should NOT be also expressed in other elements of a FHIR resource.

Is the purpose of that constraint the avoidance of redundancy, which can turn into inconsistence? Is it intended to generally favor a code (SNOMED, LOINC, or some other) code over an explicit element value?

Maybe FHIR can be used as an envelop or container for information expressed in the form of SNOMED CT expressions. This would be a good starting point for enabling a SNOMED CT-based system to use FHIR. Are there any obstacles to this path? I am assuming that all our clinical data that is in the form of SNOMED clinical kernel expressions can be put into FHIR resources as Procedure.type, Condition.code, and Observation.name.

As needed, over time, information in SNOMED expressions could be exposed to trading partners as FHIR elements using extensions, or by using defined optional elements, At that time would it be necessary to remove information from the SNOMED expressions to avoid redundancy?

I wish I could help with the specification of FHIR elements, but my knowledge is mostly theoretical. I can only compare elements of Procedure, Condition, and Observation to the SNOMED Concept model attributes for Clinical Finding and Procedure, without knowing what will be required in practice.

Best Regards,

Christopher Howell | Agfa HealthCare Software Engineer | Cardiovascular Business Unit T +1 401 604 2118 | F +1 401 596 8562

Agfa HealthCare Corporation, One Crosswind Road, Westerly, RI, 02891-3679, United States http://www.agfahealthcare.com http://blog.agfahealthcare.com Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer

---

From: Grahame Grieve <grahame@healthintersections.com.au> To: Christopher Howell/AWWRF/AGFA@AGFA Cc: "fhir <fhir@lists.hl7.org>" <fhir@lists.hl7.org>, hl7_pat care <patientcare@lists.hl7.org> Date: 04/18/2014 11:50 PM Subject: Re: Binding Relationship Types to SNOMED CT Relationship Types Sent by: grahameg@gmail.com Grahame Grieve grahame@healthintersections.com.au via lists.hl7.org

Apr 21

to Christopher, fhir, hl7_pat Are you familiar with TermInfo? We have to revisit their work for FHIR in at least some respects, but I would think that would give general guidance.

I think that we don't really know what to do about the kinds of cases like observation where some coding systems for observation type include things like body site, specimen type, etc, and some don't. We could choose to say: 1. only allowed to use one approach 2. encode both if you use a coding system that includes both 3. only use the specific element if it's not in the code 4. Or, we could say nothing.

In practice, a small set of doctors who use systems chose the 3rd option for observation after discussion with some technical folks, and this was grand-fathered into FHIR. Of those choices:

1. I don't see how we can make that stick. That would be a clinical choice that could be enforced at some level, but we know that some jurisdictions have made different choices to others, so we can't choose 2. I don't see how we can made this stick either - it imposes the obligation to extract the specific field from the code, but a secondary translator would have a problem with this. I think it's a good idea theoretically, but it's a practical road-block to make this rule 3. This doesn't work too well, but at least you can get going in the absence of making it work well, and it doesn't interfere with more specific rules made by projects and jurisdictions where they have the control to make them 4. This is what we did in Procedure/Condition, and I think we should say #3

---

dr William TF Goossen wgoossen@results4care.nl via lists.hl7.org

Apr 21

to Grahame, Christopher, fhir, hl7_pat

Christopher, Grahame,

I wonder whether the specific description of these requirements in the Detailed Clinical Models could help here. These were created exactly for such reasons as to which are core elements and which are optional, and how to bind the data elements to various terminologies (and where applicable the value sets). Cardinalities are set as well.

A FHIR resource to ISO TS 13972 : 2014 (July) criteria for clinical content would be useful, releving FHIR from the burden of specifying every clinical concept, and still allowing clinicians to specify their requirements. We have the UML version of DCM to HL7 v3 CDA/message export, have CIMI ADL export and have FHIR export format. One HL7 DCM spec, hence would satisfy all variants. (v2 is missing, but would be a day work or so).

sincerely yours,

dr. William TF Goossen Director Results 4 Care B.V. the Netherlands De Stinse 15 3823 VM Amersfoort the Netherlands phone +31654614458 mail wgoossen@results4care.nl web www.results4care.nl www.results4care.eu chamber of commerce 32133713

---

Christopher Howell Christopher.Howell@agfa.com via lists.hl7.org

Apr 22

to Grahame, fhir, grahameg, hl7_pat Terminfo - Ahh, the penny drops... Terminology/Information Model. The "Using SNOMED CT in CDA R2 Models, Release 1" document. This group seems less accessible than the FHIR group. I'm not sure how to ask questions of this group. There are mainly announcements on the listserv. FHIR is much more friendly.

The aformentioned document does however seem to cover the ground pretty well. From a cursory reading it seems to favor using the SNOMED CT terminology. Systems that already internally use SNOMED CT expressions would seem particularly well-positioned to generate conformant CDA documents with much of the meaning expressed in SNOMED.

That terminfo document addresses most of my questions about the the use of SNOMED CT in CDA. From my point of view, the general rule of thumb is: if you can say it clearly in the terminology, use the terminology. If it can be said in the terminology, "dual representation", the decomposing of the SNOMED expression into several information elements, should only be required for a good reason.

Assuming FHIR Procedure.bodySite and HL7 Procedure.targetSiteCode are comparable, the guidance is to use a SNOMED CT expression to express it if you can. "The recommendation to use the SNOMED CT representation of site is based on its added expressivity. Omission of the HL7 targetSiteCode attribute is recommended to avoid the redundancy and the potential for conflicts between the two forms of representation of site."(2.2.6)

Also, where a system uses post-coordinated SNOMED internally, that document does not favor "disaggregating [an expression] across multiple HL7 attributes (e.g. assigning SNOMED "procedure site" to the HL7 Procedure.targetSiteCode)" (A.4)

This supports choice 3: "only use the specific element if it's not in the code"

-Chris

Best Regards,

Christopher Howell | Agfa HealthCare Software Engineer | Cardiovascular Business Unit T +1 401 604 2118 | F +1 401 596 8562

Agfa HealthCare Corporation, One Crosswind Road, Westerly, RI, 02891-3679, United States http://www.agfahealthcare.com http://blog.agfahealthcare.com Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer

---

Grahame Grieve grahame@healthintersections.com.au via lists.hl7.org

Apr 22

to Christopher, fhir, hl7_pat I think we need to revisit some of the terminfo guidance for FHIR. I know that at least one issue can't stand - the idea of using assertion for Observation.name, and folding stuff into Observation.value. It doesn't work in practice. So maybe some other stuff as well. But it would certainly be the starting point.

Grahame

--

---

http://www.healthintersections.com.au / grahame@healthintersections.com.au / +61 411 867 065

---

Lisa Nelson <LisaRNelson@cox.net>

Apr 22

to George', Benjamin, graup, Brian, John, dtao12, Keith, Brett, strucdoc, me, Christopher, Grahame, fhir, grahameg, hl7_pat

All,

I think this tread is relevant to folks from Structured Docs and Vocab, so I am broadening the distribution. I think there may be some “CDA Implementers” and CDA “enthusiasts” who really dig into the details of CDA template use, and might be able to lend some additional perspective on this. (sorry if you are double listed)

The thread below is asking about guidance regarding the semantic overlap that exists due to the available of RIM structures and terminology constructs which both support the ability the encode qualifier concepts such as “target site” and “method”.

The tread is pointing to advice documented in the January 2014 DSTU balloted for TermInfo (named "Using SNOMED CT in CDA R2 Models, Release 1"). Current ballot reconciliation comments are being discussed which question if the guidance provided in TermInfo should be slanted toward recommending a terminological solution (which it currently does), or if the job of the TermInfo IG should be to clearly explain the overlaps and the available options for dealing with overlap completely and correctly.

I’m not sure we yet have quite enough deep thinking on the topic, and the discussion hasn’t to date included a full complement of stakeholders who may have perspectives on this topic. Some are calling for a more “balanced” approach which simply requires that the template include conformance statements that address how the particular template addressed the overlap. The case is being made that there are cases where it may make more sense to utilize the available data structures in CDA than to use a terminology approach. Some of the discussion have focused on the fact that the important thing for interoperability is to have standards that are clear. One approach is not better than the other. The expectations of data representation just needs to be clear, defined ahead of time, and non-overlapping.

I would hate to see any conclusions be drawn into the development of FHIR profiles which is based on draft material from the TermInfo ballot which is not yet reconciled.

This very discussion is taking place on Wednesday mornings from 8:00am-9:30am. Rob Hausam is leading the effort, and I’m sure he and the rest of the folks working on the TermInfo ballot would welcome additional input on this question.

Below is a link to the wiki for the group who is spearheading this collaboration.

http://wiki.hl7.org/index.php?title=TermInfo_Project

Lisa

Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | www.LisaRNelson.com

cell: 401.219.1165 | Westerly, RI | LisaRNelson@cox.net

---

Robert Hausam <rrhausam@gmail.com>

Apr 22

to HL7terminfo, Christopher, Grahame, fhir, Grahame, hl7_pat Chris,

We're a very friendly bunch in TermInfo! :) And we certainly welcome both questions and participation. We also have a meeting tomorrow morning at 8:00 AM Eastern, if you're interested in joining (it's in the HL7 Conference Call calendar, or I'm happy to forward the details). I think that your reading and summarization of the current DSTU guidance is reasonably fair. We're working through the ballot reconciliation from Jan. 2014 at present, and we expect to be balloting again in the near future (probably Sept. 2014 or Jan. 2015). When we do go back to ballot, I expect that the guidance may seem to be a bit more "even-handed" between SNOMED CT and CDA R2 (or other V3 models). Even if you didn't have an opportunity to comment on the ballot, we're certainly interested in hearing your perspective at any time. And we're interested in FHIR, too!

Rob

---

Christopher Howell <Christopher.Howell@agfa.com>

Apr 23

to me, fhir, Grahame, Grahame, HL7terminfo, hl7_pat Rob,

Thanks for the invitation! I missed this week's call.

I hope that my questions and comments will be of some use to you. All of your responses are helpful to me.

My viewpoint is that of a software developer. My questions are raised to seek guidance for very near term development of a cardiology clinical reporting application. We are keen on using SNOMED CT expressions for internal representation of clinical data. It enables usage of the terminology for reasoning in conjunction with other ontologies. It is expressive amd not dependent on a particular information model.

We expect that the application with generate structured documents conformant to SOME standard.

There is great value in adopting a specification like FHIR from the beginning. A specification for RESTful API, a model for data storage and exchange of health records and usable pre-existing software have value for us. "Fast" is key. So is usable now. FHIR has these characteristics.

It seems possible to bend FHIR resouces into an easy-to-implement shape if we can use SNOMED CT expressions in Observation, Procedure and Condition resources to say it in SNOMED, and not necessarily in other resource elements . But it would be unfortunate if we painted ourselves in to a corner by doing so.

For example, having all those resources with semantic coding, I now want to do subsumption-based semantic query. If that is not possible in FHIR I have painted myself into a corner.

Another example, that I noticed just now, is this note in the FHIR documentation of the method value set for medication administration:

"Note: to avoid confusion with other attributes in this resource concepts that are pre-coordinated with site and/or route of administration (e.g. "intravenous infusion" where "intravenous" is the route or "rub into left hand" where "left hand" is the site) should not be used in this value set" (Value Set http://hl7.org/fhir/vs/administration-method-codes)

This instruction tells me to use FHIR <method> <route> and <site> elements instead of simply a SNOMED <method> code (pre-coordinated or post-coordinated), that specifies route and site.

This rule undercuts the value of a medical record containing

       431230009|Administration of substance into bladder via intravesical route using bladder catheter (procedure)|

which combines <route> <site> and <device> in the <method> code.

Future systems might be expected to get that knowledge directly from 431230009. Asking them to reconstitute it from four resource elements might be considered an unnecessary burden. In the present, I don't know what is gained by requiring a very near future system that knows SNOMED CT to decompose 431230009 in the first place.

Appreciating your comments,

Chris

Christopher Howell | Agfa HealthCare Software Engineer | Cardiovascular Business Unit T +1 401 604 2118 | F +1 401 596 8562

Agfa HealthCare Corporation, One Crosswind Road, Westerly, RI, 02891-3679, United States http://www.agfahealthcare.com http://blog.agfahealthcare.com Click on link to read important disclaimer: http://www.agfahealthcare.com/maildisclaimer

---

Grahame Grieve <grahame@healthintersections.com.au>

Apr 23

to Christopher, me, fhir, HL7terminfo, hl7_pat

   For example, having all those resources with semantic coding, I now want to do subsumption-based semantic query. 

yes you can do that, though right now I see that we have not addressed this in the specification itself. I'm hoping to work on this in the next couple of months

   Future systems might be expected to get that knowledge directly from 431230009. Asking them to reconstitute it from four resource elements might be considered an unnecessary burden. In the present, I don't know what is gained by requiring a very near future system that knows SNOMED CT to decompose 431230009 in the first place.

being able to interoperate with systems that don't know snomed ct?

---

Tony Bater (NWIS - Technical) <Tony.AJB.Bater@wales.nhs.uk>

Apr 24

to Grahame, Christopher, me, fhir, HL7terminfo, hl7_pat

Future systems might be expected to get that knowledge directly from 431230009. Asking them to reconstitute it from four resource elements might be considered an unnecessary burden. In the present, I don't know what is gained by requiring a very near future system that knows SNOMED CT to decompose 431230009 in the first place.

being able to interoperate with systems that don't know snomed ct?

That is not a very useful example. Decomposing 431230009 into atomic SNOMED CT codes for each of its constituent elements of <route>, <site> and <device> is still not much help if the system trying to interoperate with it doesn’t know SNOMED CT!

Tony Bater

Canisc Technical Lead

National Cancer Information Programme

NHS Wales Informatics Service

Phone: 029 2050 2785

WHTN: 01790 2785

Mobile: 07817 118331

Email: tony.bater@wales.nhs.uk

UKCHIP Registered Professional

---

Grahame Grieve <grahame@healthintersections.com.au>

Apr 24

to Tony, Christopher, me, fhir, HL7terminfo, hl7_pat Hi Tony

I don't think it's so simple. If you send it in a decomposed fashion, there's a limited set of things a receiving system can do that it couldn't do if it got a single code, even if it doesn't understand the codes. That includes translating between forms, and presenting more information to a user in the way they expect. Obviously a system that does not "understand" snomed would not fully understand the content either way - but "understanding snomed is not a binary thing

---

Grahame Grieve <grahame@healthintersections.com.au>

Apr 24

to Tony, Christopher, me, fhir, HL7terminfo, hl7_pat Given that this is a snomed discussion, I should not have said "translating between forms" but "translating between various message syntaxes"

Grahame

---

Charles McCay <charlie@ramseysystems.co.uk>

Apr 24

to Grahame, Tony, Christopher, me, fhir, HL7terminfo, hl7_pat Tony / Grahame

And the real pushback on this is when there is a communicating community that is routinely using a specific granular form and is required to convert in and out of the pre-coordinated form just to comply with some interface standard. Where the information does not flow outside of the communicating community this feels like unhelpful overhead - having a clean way to support such post-coordinated use of SNOMED CT within such relatively closed communities will simplify adoption in some cases - especially if there is a clear route to a more universally consistent message syntax (or "form" or whatever we are calling the SNOMED CT / FHIR binding choice).

I found something similar happened within the Retinal Screening program in England, where a "green" V3 message suite was far more acceptable than full RIM-based models using the V3 ITS - the issue was resistance to mapping in and out of an alien V3RIMish language for no medium-term benefit to a closed communicating community -- a domain-specific "green" XML representation was easier adopton option. I suspect that the same will happen for SNOMED valuesets -- if these are supplied to (relatively) isolated communicating communities at the same granularity that is being used for existing term-lists for reporting and transaction processing then this will be an easier thing to get adopted than insisting on converting in and out of a "canonical" all-in-one-code representation -- which is not to say that for more heterogeneous / generic environments the all-in-one-code approach is not simpler.

In practice I suspect that having a domain-specific version with a simple mapping to the generic version will often be worthwhile -- and will be useful supporting documentation whichever flavour of adoption is used on the wire - but it will be interesting to see how things pan out...

all the best

Charlie

Charlie McCay, charlie@RamseySystems.co.uk Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES tel +44 1743 232278 / +44 7808 570172 skype: charliemccay linkedin:charliemccay Caldicott2: To care appropriately you must share appropriately Charles McCay <charlie@ramseysystems.co.uk>

Apr 24

to Grahame, Tony, Christopher, me, fhir, HL7terminfo, hl7_pat

---

McDonald, Clem (NIH/NLM/LHC) [E] <ClemMcDonald@mail.nih.gov>

Apr 24

to Lisa, George', Benjamin, graup, Brian, John, dtao12, Keith, me, Christopher, Grahame, Brett, fhir, grahameg, hl7_pat, strucdoc

For the record, for surgical (and allied) procdures I would argue for the terminological approach. Use single SNOMED codes. It is what clinicians are used to. With good indexing and synonym user will be able to find the items quickly and those who want to do special processing or analysis can know the univers of concepts they might receive . Finally one can avoid impossible combinations

---

Christopher Howell <Christopher.Howell@agfa.com>

Apr 24

to patientcare I don't understand what pre and post coordinated mean in this message.

Accomodating a group of communicating systems that agree to use FHIR in a way that communicates clincal meaning with SNOMED CT expressions rather than as distinct resource element values would be a valuable feature.

Could a FHIR conformance statement be used in this way?

All along I have been assuming that using SNOMED in FHIR means that value sets can be defined by the SNOMED Query (Expression Constraint) language, and that post-coordinated SNOMED expressions are permitted. The value set in this case is not a finite set of SNOMED concepts or expressions that can be enumerated. Am I right about this?

Manage subscriptions - http://www.HL7.org/listservice View archives - http://lists.HL7.org/read/?forum=patientcare Unsubscribe - http://www.HL7.org/tools/unsubscribe.cfm?email=rrhausam@gmail.com&list=patientcare

---

Grahame Grieve <grahame@healthintersections.com.au>

Apr 24

to Christopher, hl7_pat Hi Christopher

I thought that Charlie used "post-coordinated" differently to the normal snomed centric use.

yes, you can write FHIR profiles/value sets to describe a particular kind of usage, and value sets can be defined by the snomed language, though I have not yet seen this ysed

Grahame

---

Robert Hausam <rrhausam@gmail.com>

Apr 24

to Grahame, Christopher, fhir, hl7_pat, HL7terminfo Grahame,

I would love to revisit this for FHIR. The ASSERTION pattern seems to be either loved or hated. :) It was created to serve a legitimate purpose, though, and I think it generally does work, when used as it was intended. But it's also pretty much a kludge, and it's easy to to misunderstand and misuse. I think we would all like to have a better and more elegant solution. We at least need to much better think through the rules around when and how we allow the use of coded data in Observation value, in conjunction with its use in name (or code in V3).

I would be interested in getting more detail on what you've found that "doesn't work in practice" - that would be very useful information to have.

Rob

---

Lisa Nelson <LisaRNelson@cox.net>

Apr 24

to HL7, Grahame, Christopher, fhir, hl7_pat

Rob,

If we get to really look at the ASSERTION pattern with an open mind, I would like to bring up some of the problems I have run into relative to document consumption and SDC data representation formats that are based on a basic “tuple” notion where data elements have a two-part representation where one parts identifies the type of data element and the other part identifies the value for the data element from the associated value domain. There is substantial work being done to move in this direction and I think the assertion pattern is going to cause problems when we get there. Perhaps we can now see more aspects of actual usage/consumption of the data which change some of the prior assessment of the benefits associated with using the ASSERTION pattern.

If we are really going to re-evaluate the positive and negative aspects of the use of ASSERTION in the code element of an observation, I think we should include some of the additional needs for other “future uses” which are getting closer and closer, like Structured Data Capture, Clinical Decision Support, and Quality Measure data capture.

Lisa

Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | www.LisaRNelson.com

cell: 401.219.1165 | Westerly, RI | LisaRNelson@cox.net

---

Grahame Grieve <grahame@healthintersections.com.au>

Apr 25

to me, Christopher, fhir, hl7_pat, HL7terminfo hi Robert

I'll try to explain my problem with the assertion pattern - and it's specific to FHIR. I don't really have an opinion about it from a RIM pov. So in FHIR, a key operation in FHIR is to search, and particular to search for observations. You can search for observations by name and/or value.

Let's take, as an example, the CCDA smoking status observation. it contains a code = ASSERTION, and the value set 2.16.840.1.113883.3.88.12.3221.6.2, which is a list of 6 snomed codes. So the equivalent in FHIR would be an observation with a fixed code assertion, and a value out of the valueset.

With this pattern, to search for information about a person's smoking status, you cannot search for the question "what is the patient's smoking status" (say, LOINC 72166-2). Instead, you have to search for an answer, hoping that it's one of these codes. How do you search for a text answer? or a null answer? You can't. or what if you find a code like this with an assertion, are you sure that it's a smoking status? (probably, in this case, but can we be sure about this in all cases?)

Unless, that is, you search by the FHIR equivalent of a template Id. So straight away, the inevitable consequence of the assertion pattern in FHIR is that the template Ids will need to be used to convey semantics. That's a very bad idea indeed for all sorts of reasons.

Further, using assertion for observation.code is not consistent with the definition of observation.name:

 Describes what was observed. Sometimes this is called the observation "code". 

Was what was observed in this case is *not* 'an assertion'. It's something much more specific.

So the assertion pattern is not - generally - appropriate for use in FHIR resources.

Grahame

p.s. when I translate CCDA assertions to FHIR resources, I find a correct LOINC code (If I can) for the code, such as in the example above.