FHIR Chat · Connectathon Terminology Services Track · implementers

Stream: implementers

Topic: Connectathon Terminology Services Track

Rob Hausam (May 07 2016 at 10:38):

Welcome to the topic for the Terminology Services track at Connectathon 12

Gana Pemmanda (May 07 2016 at 11:33):

Hi Rob, What time is the the Terminology Services track Connectathon?

Rob Hausam (May 07 2016 at 11:36):

Gana, the Connectathon begins at 9:00 AM

Gana Pemmanda (May 07 2016 at 11:37):

Thanks! I meant is there a schedule for different tracks?

Lloyd McKenzie (May 07 2016 at 11:38):

All tracks run simultaneously

Gana Pemmanda (May 07 2016 at 11:39):

Thanks! I am stuck at Detroit airport. Will make it in around 11:00 - for the afternoon session

Rob Hausam (May 07 2016 at 11:42):

Sorry. No, I am not aware of any separate schedules for different tracks. People can progress through various aspects of the track (any of them) based on their own needs, interests and capabilities. We will begin with some initial introductory information, but then everyone will turn to coding and testing. I'm sorry you are stuck - but you can start as soon as you arrive at 11:00.

Michael Lawley (May 07 2016 at 13:30):

CSIRO Ontoserver - http://52.63.0.196:8080/fhir
STU3

Rob Hausam (May 07 2016 at 13:35):

Please post your server URLs (either that you are hosting and/or intend to test) and I will add them to the Wiki (if they aren't already there)

Michael Lawley (May 07 2016 at 13:36):

John Gresh / Apelon, does your server produce json or only XML?

Grahame Grieve (May 07 2016 at 13:37):

http://fhir3.healthintersections.com.au/open

Rob Hausam (May 07 2016 at 14:45):

Check out the updated information on the NLM - FHIR services on VSAC. They have a large number of code systems and versions available for testing, and they've updated to suport STU3. They would appreciate lots of testing and feedback.

Rob Hausam (May 07 2016 at 14:48):

The NLM info is linked from the Connectathon 12 Wiki - and here's the direct link:
http://wiki.hl7.org/index.php?title=NLM_-_FHIR_services_on_VSAC

Rob Hausam (May 07 2016 at 15:43):

Is anyone checking out (or planning to check out) the CodeSystem resource specifically? If so, are there issues/concerns/suggestions?

Rob Hausam (May 07 2016 at 15:52):

Who is working with the $closure operation on ConceptMap?

Gana Pemmanda (May 07 2016 at 16:14):

Here's our URL http://healthapi.hygeiais.com/fhir/stu3. The $closure operation is not supported yet

Michael Lawley (May 07 2016 at 16:24):

@Gana Pemmanda do you support SNOMED CT ?

Gana Pemmanda (May 07 2016 at 16:25):

@Michael Lawley Currently only SNOMED CT and other inline ValueSets. Will have LOINC loaded by tomorrow..

Michael Lawley (May 07 2016 at 16:27):

I'm getting errors doing and expand on the snomed implicit valueset http://snomed.info/sct?fhir_vs
Wrong ValueSet identifier for operation "$expand"

Michael Lawley (May 07 2016 at 16:29):

Note to all, the example for $lookup here http://hl7.org/fhir/2016May/terminology-service.html is broken -- it suggests the following:
GET [base]/CodeSystem/$lookup?url=http://loinc.org&code=1963-8&properties=code,display,designations
but this should be
GET [base]/CodeSystem/$lookup?url=http://loinc.org&code=1963-8&property=code&property=display&property=designations

Rob Hausam (May 07 2016 at 16:35):

Thanks, Gana. What name would you like for your server when I list it on the Connectathon Wiki page (assuming that you want me to do that)?

Grahame Grieve (May 07 2016 at 16:53):

@Michael Lawley - can you create a task for that property thing?

Michael Lawley (May 07 2016 at 17:27):

@Grahame Grieve done - 9962

Grahame Grieve (May 07 2016 at 17:28):

thx

Michael Lawley (May 07 2016 at 17:47):

Some new servers added to the ValueSet explorer tool http://ontoserver.csiro.au/vstool/

Gana Pemmanda (May 07 2016 at 18:13):

@Michael Lawley Just noticed a bunch of issues with last night's build which we did for the CodeSystem. Will get them fixed tonite..

Michael Lawley (May 07 2016 at 18:50):

Great, thanks @Gana Pemmanda

Brian Postlethwaite (May 07 2016 at 18:53):

Soory guys, my serer hasn't been updated for the new terminology services changes for CodeSystem :(

Brian Postlethwaite (May 07 2016 at 18:54):

It might claim it does some stuff, but for the most part, I wouldn't be sure it would do much.

Michael Lawley (May 07 2016 at 19:20):

@Brian Postlethwaite as long as it doesn't claim a fhirVersion >= 1.3.0 then my vstool should be fine - just needs real SNOMED content :-)

Brian Postlethwaite (May 07 2016 at 19:21):

nice dig, but yes. And my server is reporting 1.3

Michael Lawley (May 07 2016 at 19:22):

ah, it was reporting 1.0.2 this morning

Brian Postlethwaite (May 07 2016 at 19:24):

This server?
http://sqlonfhir-may.azurewebsites.net/fhir/

Michael Lawley (May 07 2016 at 20:24):

ah, not with the -may in there

Brian Postlethwaite (May 07 2016 at 21:38):

other server is (and will stay dstu2). Decided to keep the server names up with the version of fhir.
This connectathon is a snapshot version, so gets the name May ;)

Rob Hausam (May 08 2016 at 13:51):

For all of the Terminology Track participants, if you can send to one or two bullets/notes/slides on what you've done and accomplished, that would be great. I need that by the end of the quarter (10:30) so it will be ready for our report.

Michael Lawley (May 08 2016 at 16:09):

@Grahame Grieve's server returns a 500 error when $expand is called on the SNOMED CT implicit value set. I would normally have expected a 4xx ?

Grahame Grieve (May 08 2016 at 16:09):

why?

Grahame Grieve (May 08 2016 at 16:10):

it certainly should work, it's not a client error

Grahame Grieve (May 08 2016 at 16:10):

oh is too costly?

Michael Lawley (May 08 2016 at 16:11):

Well ,message is "The code System "http://snomed.info/sct" has a grammar, and cannot be enumerated directly" which looks like either too costly or client error (a request to enumerate the infinite), even though I only ask for 10 of

Grahame Grieve (May 08 2016 at 16:12):

yeah ok, that shoudl be a 4xx. which one?

Michael Lawley (May 08 2016 at 16:13):

422 I think

Michael Lawley (May 08 2016 at 16:13):

that's what a too costly with filter returns on your server

Michael Lawley (May 08 2016 at 16:22):

The ValueSet explorer tool is publically available at http://ontoserver.csiro.au/vstool
If anyone has a server they would like me to add into the mix, just post here
Ideally it should suport CORS (otherwise I rely on http://cors.io)
It MUST support JSON

Michael Lawley (May 08 2016 at 16:24):

Question about $validate-code -- if the display string doesn't match the display of the code in corresponding $expand request should it always return false? Or, is it okay of the display matches any of the designations for the code?

Grahame Grieve (May 08 2016 at 16:33):

I think that's a policy decision

Michael Lawley (May 09 2016 at 15:28):

As a terminology services client, I keep running into three problems:
1. CORS support is not enabled (my clients are javascript apps running in a browser)
2. JSON is not supported (if you have a _simple_ way of converting application/xml+fhir to application/json+fhir in the browser, I'm all ears
3. JSON is supported, but is not returned when errors happen

Michael Lawley (May 09 2016 at 15:40):

For 1, in the vstool I am now using cors.io as a work-around. This has two issues:
1. There seems to be some rate-limiting (sometimes responses come back without the CORS header)
2. The Accept headers are not passed through, so servers such as NLM's that support JSON but do not understand the _format query parameter so XML comes back

Grahame Grieve (May 09 2016 at 15:49):

These are all general errors. We should add these to the implementers check list - can you create a task for that? You can use my server to do xml/json conversion

Michael Lawley (May 09 2016 at 16:11):

9971 created

Grahame Grieve (May 09 2016 at 16:11):

thanks

Guoqian Jiang (Nov 09 2016 at 18:29):

@Rob Hausam @Grahame Grieve What technical level and skills do you expect for the audience of the Connectathon Terminology Services Track? Do they need Java programming skills in order to understand the technical details you bring up?

Grahame Grieve (Nov 09 2016 at 19:54):

no. you can participate as a consumer if all you know is basic web API knowledge, and basic terminology knowledge

Guoqian Jiang (Nov 09 2016 at 20:31):

@Grahame Grieve great. Does this mean that your target audience of the connectathon will be consumers rather than developers?

Grahame Grieve (Nov 09 2016 at 20:49):

well, developers and analysts of consumer systems on the one said, and the service providers on the other

Peter Jordan (Jan 12 2017 at 00:47):

@Michael Lawley is there a version of Ontoserver available for testing at the San Antonio Connectathon on Saturday?

Michael Lawley (Jan 12 2017 at 01:09):

Absolutely - https://ontoserver.csiro.au/stu3-latest

Michael Lawley (Jan 12 2017 at 01:11):

I've also updated the ValueSet explorer tool (http://ontoserver.csiro.au/vstool/) with some additional endpoints and the ability to enter one of your own.

Rob Hausam (Jan 14 2017 at 12:32):

Welcome to the Terminology Services track at Connectathon 14 in San Antonio. We can use this topic for communication within our group about questions that we have, issues that we're encountering and progress that we're making. I'm looking forward to what will be accomplished over the next day and a half!

Rob Hausam (Jan 14 2017 at 13:23):

For those of you who are providing terminology service endpoints for clients to test and use, it would be great if you can verify the details for your server in the Expected participants section, and update them if needed (let me know if you aren't able to edit the Wiki or need help with updating). Also, If you encounter any other information on the Wiki pages that is outdated or incomplete, please update it or let me know.

Rob Hausam (Jan 14 2017 at 13:49):

I've updated the NLM - FHIR services on VSAC page to reflect the latest information from the NLM. It would be great if we could thoroughly test their service offerings during this Connectathon, so please do that as you have the opportunity.

Joel Schneider (Jan 14 2017 at 15:43):

For the record, here's a link to my experimental terminology service for HLA nomenclature.
http://mac-and-fhir-prototype.us-east-1.elasticbeanstalk.com/
The landing page includes a Postman collection containing a few usage examples. Caveats: it only recognizes a limited set of code systems and value sets, and it was originally developed for DSTU2 and has not yet been updated for STU3.

Rob Hausam (Jan 14 2017 at 15:45):

The terminology track is distributed across at least 3 different tables today, so let's try to make maximum use of the chat for collaboration. It would be great if we could all post something about what we're offering in regard to servers and clients and what we hope to accomplish over the next day and a half.

Joel Schneider (Jan 14 2017 at 15:59):

In addition to the prototype terminology service, I've also been working on a STU3 terminology bundle for HLA which could be loaded into a typical FHIR server.

Grahame Grieve (Jan 14 2017 at 16:19):

Joel - that would be great. But it was my impression that proper support for HLA would require implicit knowledge beyond what we could represent in CodeSystem?

Grahame Grieve (Jan 14 2017 at 16:20):

I'm going to have a shot a simple implemention of $compose for snomed

Joel Schneider (Jan 14 2017 at 17:20):

Grahame - For nomenclature-level HLA data, I think CodeSystem(s) would be a good starting point.

The IMGT/HLA nomenclature formally releases a new version every 3 months, so for that nomenclature I think it would not be unreasonable to periodically generate & load a new CodeSystem version for each new release.

The NMDP multiple-allele code system is a different animal. New allele codes are being defined every day, and there's no formal versioning or release process. To represent that as a CodeSystem, I think it would be possible to implement the terminology service as a gateway api that, when needed, calls another service to query the present status. It may also be possible to generate a "snapshot" bundle that captures the state of the code system at a specific point in time.

Depending on usage requirements, it might also be useful to define one or more ConceptMap resources, to implement $translate..

Joel Schneider (Jan 14 2017 at 18:02):

Last November there was some discussion using Swagger to describe FHIR terminology service APIs (here). Has there been further progress on that?

Grahame Grieve (Jan 14 2017 at 19:41):

no; I've been focusing on qa work in the spec itself. I'm expecting to work on swagger APIS in february

Grahame Grieve (Jan 14 2017 at 19:42):

have you generated a codeSYstem definition for HLA>

Joel Schneider (Jan 14 2017 at 20:21):

I've taken an initial stab at generating a CodeSystem & ValueSet bundle for the IMGT/HLA names, but it needs more work. If you're interested, I'd be happy to share/discuss it.

Grahame Grieve (Jan 14 2017 at 20:34):

sure I'll look

Joel Schneider (Jan 14 2017 at 21:12):

2017-01-15: deleted fhir-imgt-hla-terminology-bundle.xml
See below for revised file.

Joel Schneider (Jan 14 2017 at 21:19):

I'm thinking of adding properties, and more codes to it.

Grahame Grieve (Jan 15 2017 at 16:34):

ok, this will work on my server in a few minutes:

<Parameters xmlns="http://hl7.org/fhir">
  <parameter>
    <name value="system"/>
    <valueUri value="http://snomed.info/sct"/>
  </parameter>
  <parameter>
    <name value="exact"/>
    <valueBoolean value="true"/>
  </parameter>
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="focus"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="118245000"/>
    </part>
  </parameter>
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="363714003"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="302787001"/>
    </part>
  </parameter>
</Parameters>

Grahame Grieve (Jan 15 2017 at 16:35):

post to http://fhir3.healthintersections.com.au/open/CodeSystem/$compose

Grahame Grieve (Jan 15 2017 at 17:29):

.. can't get it uploaded to use on the server...

Grahame Grieve (Jan 15 2017 at 18:12):

yay works

Joel Schneider (Jan 15 2017 at 19:00):

Here's a revised HLA CodeSystem & ValueSet bundle file. I changed the bundle type to transaction and added bundle.entry.request elements. Should work better now.
fhir-imgt-hla-terminology-bundle.xml

Joel Schneider (Jan 15 2017 at 19:05):

An example curl script to load the bundle into a FHIR server:

#!/bin/sh

BUNDLE_FILENAME="$1"
if [ -z "${BUNDLE_FILENAME}" ]; then
    BUNDLE_FILENAME="fhir-imgt-hla-terminology-bundle.xml"
fi

SERVICE_URL="$2"
if [ -z "${SERVICE_URL}" ]; then
    SERVICE_URL="http://localhost:8080/baseDstu3"
fi

curl \
  --silent --show-error \
  --data \@${BUNDLE_FILENAME} \
  --header "Content-Type: application/xml+fhir" \
  ${SERVICE_URL} \
  | xmllint --format -

Rob Hausam (Jan 16 2017 at 12:05):

Thanks, Joel. I'll try to take some time to look at and work witjh this.

Peter Jordan (Jan 16 2017 at 16:25):

$compose example works for me! Returns concept 365786009 |Bilirubin level - finding|. Sub-second response! Exact setting filters out concepts with the same (proximal primitive) focus concept and attribute/value combination, but additional attributes. One up for pre-computing the normalised expressions of each concept.

Richard Ettema (Jan 16 2017 at 16:31):

If you send me examples of your $compose request and response messages, I can work on adding new TestScripts for them.

Peter Jordan (Jan 16 2017 at 16:34):

Grahame's example request is above - but it may be a little early for Test Scripting!

Response was

<?xml version="1.0" encoding="UTF-8"?>
<Parameters xmlns="http://hl7.org/fhir">
    <parameter>
        <name value="match"/>
        <part>
            <name value="code"/>
            <valueCoding>
                <system value="http://snomed.info/sct"/>
                <code value="365786009"/>
                <display value="Bilirubin level - finding"/>
            </valueCoding>
        </part>
    </parameter>
</Parameters>

Richard Ettema (Jan 16 2017 at 16:44):

Never too early! :)

Grahame Grieve (Jan 16 2017 at 17:14):

here's my pseudo code:

findMatchingConcepts(list, focus, refinements)
  children = get defined childrren(focus);
  for each child in children 
    exp = loadDefinition of child
    move all refinements on exp into refinementGroups on exp

    allMatched = true;
    oneUnMatched = false;
    grps = new List;
    for each grp in exp.refinementGroups
      state := checkGroupStateInRefinements(grp, refinements, grps);
      if (state = No Match)
        oneUnMatched = true
      else if (state != Identical)
        allMatched := false;

    if (oneUnMatched) then
      // neither this nor any of the children will ever match
    else if (allMatched) and (grps.count > 0) then
      // this reference is a complete match. stop here
      list.Add(TMatchingConcept.Create(s));
    else
      // get the list of non-matches
      grpNM = list Groups that didn't match(refinements, grps);
      if (grpNM.Count < refinements.Count) then // partial match
        list.Add(TMatchingConcept.Create(s, grpNM));
      findMatchingConcepts(list, child, grpNM);

Peter Jordan (Jan 16 2017 at 17:53):

Might be worth waiting until the exact input parameter has been added to the latest build (GF #12605). Current example in the spec also needs updating (GF #12609).

Michael Lawley (Jan 16 2017 at 23:17):

Typos in the spec for $compose:
none of the closing </part> tags include the /;
the system parameter has valuUri not valueUri (missing e).

Michael Lawley (Jan 16 2017 at 23:18):

Grahame's server complains about the mode parameter:
<issue>
<severity value="error"/>
<code value="code-invalid"/>
<diagnostics value="Only 'machine' is supported for mode"/>
</issue>
But that is the value I supplied :)

Michael Lawley (Jan 16 2017 at 23:19):

ah, I see the parameter has changed from mode to exact - looks like the error message needs updating

Grahame Grieve (Jan 17 2017 at 00:51):

sorry, incomplete changes applied in a hurry during the connectathon

Daniel Karlsson (Jan 18 2017 at 22:28):

Some comments to the $compose operation. 0. what is the intended audience of the operator (as in relation to those who post-coordinate using compositional grammar) 1. the example is ... interesting. The result is a primitive concept and does not in the current version (or daily build) of SNOMED CT have the severity property. Also, should primitives be returned when exact=true? What should be returned when there is no fully defined concept? 2. What does "partial" mean? A subsumer? 3. How does the list of parameters address relationship grouping? Cheers, Daniel

Grahame Grieve (Jan 19 2017 at 03:19):

I'm not sure what you mean about the operator

Grahame Grieve (Jan 19 2017 at 03:19):

clearly the example needs work. If severity is not in the concept, it needs to be listed in unmatched. I'll cross the example with my implementation and intl snomed

Grahame Grieve (Jan 19 2017 at 03:20):

if there is no fully defined concept, can return a partial with a list of things not matched.

Grahame Grieve (Jan 19 2017 at 03:21):

should primitives be returned...? I am returning primitives, but I can see that this may be problematic.

Grahame Grieve (Jan 19 2017 at 03:21):

perhaps I should only return them if exact=false

Grahame Grieve (Jan 19 2017 at 03:22):

2. partial means that the concept matches for some properties, but not others

Grahame Grieve (Jan 19 2017 at 03:22):

I should provide an example that deals with relationships grouping

Grahame Grieve (Jan 19 2017 at 03:22):

are you happy to add a task relating to this to gForge?

Joel Schneider (Jan 19 2017 at 16:34):

@Rob Hausam I've generated a new iteration of that IMGT-HLA terminology bundle. This one includes a set of concept properties which I think enable some interesting $closure possibilities. The file size is 45 Mb (over 10x the previous size), so instead of attaching it here, it seemed better to upload it to S3:
https://s3.amazonaws.com/nmdp-fhir-terminology/fhir-imgt-hla-terminology-bundle.xml

Michael Lawley (Jan 19 2017 at 23:37):

re $compose I think I already opened a rtackr item about the missing severity issue
I think returning a primitive is fine as long as the focus is the primitive
I'm also troubled about the use-cases motivating this opreration -- the questions raised about behaviour for exact=false and returning unmatched properties can only really usefully be resolved if the use cases are well understood.

A final point: if this operations is meant for SNOMED, then the ECL offers a better, pre-existing, approach for doing this kind of thing. If it's for other code systems as well (LOINC?) then we'll need some good clarification of the intended semantics as there would seem to be tension between what makes sense in a closed-world model as used for LOINC, and an open-world, subsumption model as used for SNOMED.

Jim Steel (Jan 20 2017 at 00:08):

@Joel Schneider just by way of some (unsolicited) feedback on that bundle. The CodeSystem resource doesn't validate against the shareablecodesystem profile, since that profile (for better or for worse) mandates the concept.definition attribute

Daniel Karlsson (Jan 20 2017 at 01:09):

will remove "severity" and keep the rest in the tracker item. Is there some description of the use case(s) served?

Daniel Karlsson (Jan 20 2017 at 01:15):

Primitives have some unstated meaning not among and additional to the defining relationships, hence they should not be returned. Has nothing to do with focus concept.

Grahame Grieve (Jan 20 2017 at 02:46):

primitives might be returned for exact = false with a note? But in some cases, SNOMED CT is too conservative when using primitive=true, and there is no important information not encoded. I think it's a line ball call. but some examples would probably be good

Grahame Grieve (Jan 20 2017 at 02:47):

$compose is certainly for LOINC and RxNorm as well. and any medication terminology. LOINC is not usable yet, but Dan says that we'll see part codes in June, and then it will be

Michael Lawley (Jan 20 2017 at 03:51):

@Daniel Karlsson If the compose request includes just the focus concept and it is primitive, then should it not be a match (exact)?
Similarly, if the focus is a primitive concept, and there is one additional property that is also part of the definition of that concept, then why would it not be a match?

Daniel Karlsson (Jan 20 2017 at 15:28):

@Michael Lawley OK, got it! Both valid cases when a primitive should be returned (but the former seems less meaningful). My problem was if the operation returns primitive subsumees of the resulting (non-precoordinated) expression. I'm still not sure what the use cases are. I have two guesses though: 1. searching the terminology (e.g. searching SNOMED CT using focus+refinements) or 2. creating expressions (e.g. dagger-asterisk coding for ICD-10, post-coordination). If it's 1, then is it supposed to be a light interface to ECL or DLQuery?

Joel Schneider (Jan 20 2017 at 15:32):

@Jim Steel Thanks for the feedback. I still need to figure out how to run a validator on the CodeSystem. It may be possible to automatically populate the concept.definition of the 15000 specific allele names and 3000 ambiguous allele names with boilerplate text ...

Daniel Karlsson (Jan 20 2017 at 15:43):

@Grahame Grieve @Michael Lawley Yes, SNOMED might be too restrictive but that's what we have...
One interesting example would be:
focus=clincial finding
morphology=fracture
finding site=structure of ulna
finding site=structure of radius
For a search use case, it would be straight forward to find 75857000 | Fracture of radius AND ulna (disorder) |, corresponding to ECL << |finding|:|morph|=|fracture|,|site|=|ulna|,site=|radius|
For a composition use case, it would require more knowledge to deduce that the two finding sites should be in separate relationship groups.

Joel Schneider (Jan 25 2017 at 21:46):

@Jim Steel @Grahame Grieve FYI, I've updated that IMGT/HLA terminology bundle: https://s3.amazonaws.com/nmdp-fhir-terminology/fhir-imgt-hla-terminology-bundle.xml

Still have more improvements in mind, but this one at least passes validation by the HAPI FHIR 2.2 STU3 FhirInstanceValidator.

Peter Jordan (Jan 30 2017 at 04:31):

Just deployed a first attempt at implementing the CodeSystem $compose operation on my server, so please feel free to POST to...
http://its.patientsfirst.org.nz/RestService.svc/Terminz/CodeSystem/$compose
Just a few caveats - Code System must be SCT; requires a focus concept and at least one attribute and value; only exact matches supported. Grahame's example above works, but it would be great to have a few other, more complex, test cases.

Daniel Karlsson (Jan 30 2017 at 12:34):

Hi Peter,

Daniel Karlsson (Jan 30 2017 at 12:37):

Hi Peter,
just tried this example:

<Parameters xmlns="http://hl7.org/fhir">
<!-- use SNOMED CT rules -->
<parameter>
<name value="system"/>
<valueUri value="http://snomed.info/sct"/>
</parameter>
<!-- 125605004 | Fracture of bone (disorder) | -->
<parameter>
<name value="property"/>
<part>
<name value="code"/>
<valueCode value="focus"/>
</part>
<part>
<name value="value"/>
<valueCode value="125605004"/>
</part>
</parameter>
<!-- Finding site: ulna -->
<parameter>
<name value="property"/>
<part>
<name value="code"/>
<valueCode value="363698007"/>
</part>
<part>
<name value="value"/>
<valueCode value="23416004"/>
</part>
</parameter>
<!-- complete and partial matches only (nothing fuzzy/indeterminate) -->
<parameter>
<name value="exact"/>
<valueCode value="true"/>
</parameter>
</Parameters>

but got no exact match.

Was expecting 54556006 | Fracture of ulna (disorder) |

Were my expectations wrong?

/Daniel

Peter Jordan (Jan 30 2017 at 21:09):

@Daniel Karlsson thanks for the testing; that query will return an OperationOutcome exception because the exact parameter should be a boolean data type, not a code. However, even with that correction, neither Grahame's or my server will return an exact match of 54556006|Fracture of ulna (disorder)| because that concept has an additional attribute of
116676008|Associated morphology|=72704001|Fracture|. If you add that attribute to the query, my server will return
54556006|Fracture of ulna (disorder)|

@Grahame Grieve server still does not return any concepts but, when back on deck, he should be able to explain why.

(Edit must state that I'm still using the 20160731 release of the International Edition).

Full POST is...

<Parameters xmlns="http://hl7.org/fhir">
  <parameter>
    <name value="system"/>
    <valueUri value="http://snomed.info/sct"/>
  </parameter>
  <parameter>
    <name value="exact"/>
    <valueBoolean value="true"/>
  </parameter>
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="focus"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="125605004"/>
    </part>
  </parameter>
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="363698007"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="23416004"/>
    </part>
  </parameter>
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="116676008"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="72704001"/>
    </part>
  </parameter>
</Parameters>

Daniel Karlsson (Jan 31 2017 at 10:50):

[[@Peter Jordan ]] sorry about the valueBoolean issue, a copy/paste error. The 125605004 | Fracture of bone (disorder) | concept includes that exact morphology in the definition. Should the operation not take this into consideration? If so, why not and what is the use case to be served?

Daniel Karlsson (Jan 31 2017 at 12:14):

Sorry about the valueBoolean, copy/paste error...
Still, the concept 125605004 | Fracture of bone (disorder) | includes the morphology in the definition. Is this service not expected to take this into account? If so, why not?
/Daniel
As you can see I've had internet connection problems today...

Rob Hausam (Jan 31 2017 at 19:25):

Great work, Peter. I'll try to do some testing and will let you know how it goes.

Peter Jordan (Feb 01 2017 at 04:15):

@Daniel Karlsson In terms of expectations - it may be easier if I provide a simple list of the steps that I'm taking to compose, and then you can tell me what I may need to add to determine that the |associated morphology| attribute is in the concept definition...

a. Select the proximal primitive(s) of the Focus Concept
b. Select all concepts that have each of the passed attribute/value pairs AND have the same proximal primitives as the Focus Concept
c. Exclude all concepts that have additional attribute/value pairs to those passed in the query

Is it significant that the Focus Concept is fully-defined? Should I be adding the attributes already in the definition of the focus concept in those (or all) cases to those contained in the query IF they are not already there. What if they are in the concept definition but have a different value to that passed in the query, as is the case with |Finding site| in this example?

Daniel Karlsson (Feb 01 2017 at 14:25):

[[@Peter Jordan ]] In the { focus=fracture of bone, finding site=ulna } example the primitive(s) would be { disease }, but the morphology=fracture of the fracture of bone definition is lost. If the focus concept(s) is/are fully defined the attributes/values would have to be added in step b. As I understand the requirements only the most specific attribute/value should be used for (exact) comparison.

Peter Jordan (Feb 06 2017 at 08:57):

@Daniel Karlsson I've now added the additional step that you advised. If the focus concept is fully defined then any of its attributes not passed in the request are added to the query processed in step b above. Maybe you can test this implementation when time permit? BTW: my server now contains the 20170131 version of the International Edition.

Grahame Grieve (Feb 06 2017 at 09:01):

hmm I'm falling behind here; will have to catch up...

Daniel Karlsson (Feb 06 2017 at 13:22):

[[@Peter Jordan ]] Did test the pervious example and I got the expected (or at least what I expected...) result. Great!

<Parameters xmlns="http://hl7.org/fhir">
    <parameter>
        <name value="match" />
        <part>
            <name value="code" />
            <valueCoding>
                <system value="http://snomed.info/sct" />
                <code value="54556006" />
                <display value="Fracture of ulna" />
            </valueCoding>
        </part>
    </parameter>
</Parameters>

Daniel Karlsson (Feb 06 2017 at 13:27):

[[@Peter Jordan ]] Tried this one expecting 75857000 | Fracture of radius AND ulna (disorder) | but got "no exact match". Please check if I did something wrong. Also (by mistake), I tried having the previous example with a duplicate finding site parameter (i.e. two finding site=ulna) also with "no exact match" result.

Perhaps it has to do with step c. The ulna&radius fracture has two role groups, each with a finding site and with an assoc. morph.=fracture. Tried adding an additional parameter, but that didn't help.

<Parameters xmlns="http://hl7.org/fhir">
  <!-- use SNOMED CT rules -->
  <parameter>
    <name value="system"/>
    <valueUri value="http://snomed.info/sct"/>
  </parameter>
  <!-- 125605004 | Fracture of bone (disorder) | -->
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="focus"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="125605004"/>
    </part>
  </parameter>
  <!-- Finding site: ulna -->
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="363698007"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="23416004"/>
    </part>
  </parameter>
  <!-- Finding site: radius -->
  <parameter>
    <name value="property"/>
    <part>
      <name value="code"/>
      <valueCode value="363698007"/>
    </part>
    <part>
      <name value="value"/>
      <valueCode value="62413002"/>
    </part>
  </parameter>
  <!-- complete and partial matches only (nothing fuzzy/indeterminate) -->
  <parameter>
    <name value="exact"/>
    <valueBoolean value="true"/>
  </parameter>
</Parameters>

Peter Jordan (Feb 07 2017 at 00:00):

@Daniel Karsson thanks again for the feedback. On an exact match I would have thought it reasonable to assume that passing duplicate attribute/value combinations would be to request concepts where these exist in different relationship groups? If so, the response, to the request sent in error, is correct. I will take a close look at the example where you were expecting 75857000 | Fracture of radius AND ulna (disorder) |. It's a good use case as it has the same pair of attributes in 2 relationship groups; in one case the value is the same, in the other it's different!

Michael Lawley (Feb 07 2017 at 01:50):

@Peter Jordan sorry, I'm late to this - I don't understand why you'd do step (a) - proximal primitives at all.
But I'm also confused - about the desired semantics. I think I resolved that (with exact=true), the corresponding ECL is:
<<125605004 :
363698007 = 23416004,
116676008 = 72704001,
[2..2] << 410662002 = *
i.e.
<< {focus} :
{property} = {value} ...
[k..k] << 410662002 = *
where 'k' is the number of supplied property value pairs.

However, this will not work properly when role grouping is in play and, for example, a finding site / value is specified but occurs in multiple groups (because 'k' will be wrong).

Michael Lawley (Feb 07 2017 at 01:52):

Where I'm confused is should this match at all - does 'exact' apply to the focus concept, or does it just mean "must have exactly the property-values specified and nothing else"?

Grahame Grieve (Feb 07 2017 at 01:53):

I think you are all looking it from a purist point of view, where as the question should be asked from a consumer point of view - I have these different elements and I'm trying to reason across them

Michael Lawley (Feb 07 2017 at 02:04):

I guess I'm trying to understand what the consumer wants when they "reason across them"? What might help is a number of example requests and expected responses. For @Daniel Karlsson 's original one, I was assuming that only the single concept |54556006 |Fracture of ulna| should match and not the additional concept 275366009 |Birth fracture of ulna| (because that has the |Occurrence| property), nor 71555008 |Closed fracture or ulna| because the morphology value is 20946005 |Fracture, closed| which is a child of 72704001|Fracture| (see http://ontoserver.csiro.au/shrimp/?concept=54556006&versionId=http%3A%2F%2Fsnomed.info%2Fsct%2F32506021000036107%2Fversion%2F20170131)

Michael Lawley (Feb 07 2017 at 02:07):

Maybe instead the consumer wants all codes that are 'subsumed' by the post-coordinated expression? (ignoring role grouping).
In terms of the ECL, this would be:

<< 125605004 : <<363698007 = <<23416004, <<116676008 = <<72704001

which matches 52 codes in SNOMED CT-AU 20170131

Grahame Grieve (Feb 07 2017 at 02:17):

typical use cases from my pov:
- I have an observation with a code and no method, and an observation with a code and a method. Are they the same?
- I have a condition with a code and a severity, and I have to convert it to a condition with a code that includes the severity (or vice versa)
- I have an observation with a related observation about stage, does that represent a stage iV cancer of the type I am interested in

Peter Jordan (Feb 07 2017 at 02:19):

@Michael Lawley What's the use case for attempting to compose using a fully-defined focus concept without going back to its proximal primitives? Aren't we effectively trying to use equivalence testing techniques here - i.e. find me a concept that's equivalent to this Normal Form definition?

Grahame Grieve (Feb 07 2017 at 02:34):

also this: http://www.healthintersections.com.au/?p=658

Peter Jordan (Feb 07 2017 at 03:07):

That Health Intersections post tells me attempting to use the compose operation to return 162573006 |Suspected lung cancer| is going to be extremely challenging! The definition of that concept is completely counter-intuitive to an endpoint system containing values of diagnosis=cancer, finding site = lung, status = suspected....

243796009|Situation with explicit context|:{408729009|Finding context|=415684004|Suspected|,246090004|Associated finding|=363358000|Malignant tumour of lung|,408731000|Temporal context|=410512000|Current or specified|,408732007|Subject relationship context|=410604004|Subject of record|}

Grahame Grieve (Feb 07 2017 at 03:35):

that's an SCT problem then?

Peter Jordan (Feb 07 2017 at 04:05):

I'd suggest that your blog entry leads to that conclusion. Hopefully, there are sufficient positive examples to justify implementing this operation. Perhaps one fertile area might be the new pre-coordinated concepts in the 20170131 version with laterality attributes. Maybe @Daniel Karlsson could suggest some examples.

Daniel Karlsson (Feb 07 2017 at 11:11):

I guess it is ;) but that's what the template work is aiming to address. I'm trying to figure out what the exact use case is for the $compose operation, i.e. what the consumer view of this is and if that can be compatible with a purist view, which is finally going to be needed when implementing the stuff. E.g. we need to specify what to do with subsumption (is it a query operation?), relationship groups and multiple instances of relationships, nested definitions?, is it a "light" interface/a transform to ECL?
I'm not sure we need more examples, ulna+radius fracture and suspected lung cancer would cover these complexities of SNOMED CT, but maybe a page with examples and expected outcomes? E.g. would it be expected that the $compose operation would manage the Suspected cancer use case?

Peter Jordan (Feb 08 2017 at 00:13):

If a Focus Concept of 162572001 |Suspected Cancer| and attribute/value pair of 246090004|Associated finding|=363358000|Malignant tumour of lung| are passed to my server it will return 162573006 |Suspected lung cancer|. The difficulty in the broader example lies where the Focus Concept is a Disease (e.g. 93880001|Primary malignant neoplasm of lung) rather than a Situation with explicit context. This probably requires some complex business logic based on the detection of aFinding Context attribute. From an end-user perspective, it might just be easier to request an expansion of the SCT Implicit Value Set with a text filter of "suspected lung cancer".

Michael Lawley (Feb 08 2017 at 07:27):

@Peter Jordan I guess that's what I'm struggling with; it looks to me like most cases are do-able with either ECL (which is already available via ValueSet) or a subsumption test. But I suspect what's desired is something closer to smart selection of an appropriate template (as @Daniel Karlsson refers to).
As we can see with the suspected lung cancer example, we quickly run into the boundary/impedance mismatch between the information model and the SNOMED concept model.
@Daniel Karlsson - yes that's what I'm after. To implement this I need to know what the expected outcomes are and where it is reasonable to draw boundaries.

Grahame Grieve (Feb 08 2017 at 11:48):

I don't see how 'the cases' are do-able via value set

Grahame Grieve (Feb 08 2017 at 11:48):

it's a completely different API

Christopher Schuler (Feb 08 2017 at 21:07):

Is there a code system defined for MeSH (https://meshb.nlm.nih.gov)? I was looking for a reference here: http://build.fhir.org/terminologies-systems.html, but couldn't find anything. I am using the MeSH AgeGroupObservationValue value set in an example:

"useContext": {
      "code": {
        "system": "http://hl7.org/fhir/usage-context-type",
        "code": "age"
      },
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "https://meshb.nlm.nih.gov",
            "code": "D000328",
            "display": "Adult"
          }
        ]
      }
    }

Michael Lawley (Feb 08 2017 at 22:54):

- I have an observation with a code and no method, and an observation with a code and a method. Are they the same?
This is a subsumption test with postcoordination of the second code + method

- I have a condition with a code and a severity, and I have to convert it to a condition with a code that includes the severity (or vice versa)
This is postcoordination (going forwards) or, to extract the severity, you would use the ECL and expand the ValueSet with compose.include.filter.{property = constraint, op = =, value = [code].severity} -- this example seems to cover http://www.healthintersections.com.au/?p=658 as well, I think.

- I have an observation with a related observation about stage, does that represent a stage iV cancer of the type I am interested in
This one is hard because:
a) the question is not clearly defined - what is the valueset for the stage observation? If it's << Clinical stage finding then you're out of luck because these are not linked to specific cancers. If it's << Tumor stage finding then you're okay and the remaining question is how is "of the type I am interested in" represented?
b) SNOMED is not particularly mature in representing (modelling) this information. Looking at Carcinoma of ovary, stage 4 and Carcinoma of colon, stage 4 there's no "stage 4" in the relationships, so the only way $compose or anything else is going to be able to answer this is with additional domain knowledge - where does this come from?

Grahame Grieve (Feb 09 2017 at 03:50):

@Christopher Schuler please create a task to define a URL for MeSH

Grahame Grieve (Feb 09 2017 at 03:52):

@Michael Lawley I'll have to try and think about this tomorrow. my initial response is that maybe you're right, but oo do them with existing operations requires a lot of knowledge of SCT, and we're trying to get away from the client needing to know that

Peter Jordan (Feb 09 2017 at 04:25):

@Daniel Karlsson My server now returns75857000 | Fracture of radius AND ulna (disorder) | when you POST that query. It identifies when you pass >1 parameter with the same attribute and reasons that there must be relationship grouping and adds the attributes of the focus concept to each group. Not sure how many more hoops I can jump through!
[Edit]...Updated process is now:
a. Select the proximal primitive(s) of the Focus Concept posted in the request.
b. Detect multiple instances of the same attribute posted in the request (>1 denotes relationship grouping).
c. If the Focus Concept is fully-defined, add any attribute/value pairs not included in the request (one for each group where grouping detected at stage b. above).
d. Select all concepts that have each of the combined set of attribute/value pairs AND the same proximal primitives as the Focus Concept.
e. Exclude all concepts that have additional attribute/value pairs to the combined set of attribute/value pairs.

Daniel Karlsson (Feb 09 2017 at 09:31):

[[@Peter Jordan ]] I'm still not sure about step b. Should multiple relationships of the same kind be necessary for matching multiple role groups? Or not? Did your query include an additional assoc.morphology=fracture part? I think we need to more clearly specify what is expected from this operation. From comments it seems like the aim is for a lightweight ECL. I'll set up a google doc (ok?) with some examples and then we can discuss our (varying?) expectations on results.
https://docs.google.com/document/d/1fOftp1mjL0ypFioG0_AwbYmfgxg9tw1SR3ZqzOUWUIo/edit?usp=sharing

Peter Jordan (Feb 09 2017 at 22:57):

@Daniel Karlsson For the Fracture of radius AND ulna example, I posted the same request as in your entry of 7th Feb above. As the focus concept is fully-defined 125605004 |Fracture of bone|, I added the Associated morphology=Fracture attribute from that concept to the set of attributes (stage c. above) to the query executed at stage d. above. I'll try the examples on the Google Doc - it would be good to add these to the document...
1. Returns Operation Outcome - error - "Must submit at least one Attribute/Value Pair Property". What else would you really expect if all that's posted in the query is a single focus concept?
2. Returns 73211009 | Diabetes mellitus |. Echoes back what was sent in the request as it's the only exact match. Good test of where a focus concept is its own proximal primitive (had to correct my T-SQL TVF to handle this!).

Peter Jordan (Feb 12 2017 at 03:48):

3. Returns 54556006 |Fracture of ulna|
4. Returns 75857000|Fracture of radius AND ulna|
5. Returns no exact matches - expected behaviour is not yet stated
6. Returns no exact matches (expected)
7. Returns no exact matches - expected behaviour

It might be good to add some of the other, simpler, examples that work to the Google Doc to give a more positive perspective on the potential uses of the operation.

Peter Jordan (Feb 17 2017 at 00:52):

$compose example in the spec (latest build) doesn't work on my Server or Grahame's (whether it should is up for debate, although passing a fully defined focus concept and expecting a primitive in return may be unrealistic) and has an incorrect rendering of the exact parameter. Appreciate that it may be too late to change this for R3, unless examples can be changed in the Review process. Test 3 or 4 in Daniel's Google Doc would be better.

Grahame Grieve (Feb 17 2017 at 01:28):

it's not too late yet

Grahame Grieve (Feb 17 2017 at 01:28):

close though

Peter Jordan (Feb 17 2017 at 01:51):

Successfully added [#12852] to gForge - assigned to Product Director due to shortage of time. I used your example, near the top of this thread, that returns 65786009 |Bilirubin level - finding|.

Grahame Grieve (Feb 17 2017 at 05:02):

which is my bilirubin example @Peter Jordan ?

Peter Jordan (Feb 17 2017 at 05:12):

<Parameters xmlns="http://hl7.org/fhir"> <parameter> <name value="system"/> <valueUri value="http://snomed.info/sct"/> </parameter> <parameter> <name value="exact"/> <valueBoolean value="true"/> </parameter> <parameter> <name value="property"/> <part> <name value="code"/> <valueCode value="focus"/> </part> <part> <name value="value"/> <valueCode value="118245000"/> </part> </parameter> <parameter> <name value="property"/> <part> <name value="code"/> <valueCode value="363714003"/> </part> <part> <name value="value"/> <valueCode value="302787001"/> </part> </parameter> </Parameters>

Grahame Grieve (Feb 17 2017 at 05:12):

thx

Peter Jordan (Feb 17 2017 at 05:14):

...returns
<Parameters xmlns="http://hl7.org/fhir"> <parameter> <name value="match" /> <part> <name value="code" /> <valueCoding> <system value="http://snomed.info/sct" /> <code value="365786009" /> <display value="Bilirubin level - finding" /> </valueCoding> </part> </parameter> </Parameters>

Grahame Grieve (Feb 17 2017 at 05:18):

so I'm going to refer this whole thread to Snomed International via Jane to ask that they confirm that this is the sort of thing SCT should be able to do, and that they consider how to be able to respond to the kind of problems this tthread has thrown up

Peter Jordan (Feb 17 2017 at 05:19):

Focus concept is 118245000 |Measurement finding| attributes are 363714003 |Interprets| = 302787001 |Bilirubin measurement|

Peter Jordan (Feb 17 2017 at 05:24):

I look forward to their response with interest. FWIW, my take is that the glass is more than half full, and the operation will be of value to terminology clients. If it exposes some issues that will result in the improvement of both SCT and FHIR, that will be a good outcome all round.

Michael Osborne (Feb 21 2017 at 09:16):

Looks like an overly elaborate way to query a terminology service to me. What's wrong with using the SNOMED CT Expression constraint language in a query?

Grahame Grieve (Feb 21 2017 at 10:46):

because SCT is not the only terminology, and few people know the ECL, and I don't know how you would do what this actually does with ECL - ECL has the same logic, but this is not about logic, it's about how to expose the process to an application. ECL might well be part of the implementation for a server

Grahame Grieve (Feb 21 2017 at 10:46):

actually ECL is a subset of the same logic

Ewout Kramer (May 06 2017 at 09:36):

Is there a reason we have a CodeSystem resource for snomed (http://hl7.org/fhir/codesystem-snomedct.xml) but not for LOINC?

Grahame Grieve (May 06 2017 at 09:40):

LOINC asked us not to because they're going to host it themselves

Grahame Grieve (May 06 2017 at 09:40):

but here's what we've agreed:

Grahame Grieve (May 06 2017 at 09:41):

loinc.xml

Last updated: Apr 12 2022 at 19:14 UTC