Stream: terminology / utg
Topic: Progress
Grahame Grieve (Dec 12 2019 at 00:31):
@Ted Klein I have just rebuilt UTG - please check that heirarchical display issue. but this is a transient thing - need to build the code systems properly
Grahame Grieve (Dec 12 2019 at 00:32):
displaying properties on codes - this is also directly linked to how the properties are defined. When they haev formal URLs defining them, then they can be displayed
Grahame Grieve (Dec 12 2019 at 00:32):
what does <title> not being displayed mean?
Grahame Grieve (Dec 12 2019 at 00:32):
@Lloyd McKenzie the template works now
Ted Klein (Dec 12 2019 at 02:18):
@Grahame Grieve 'tis a thing a' beauty. Thanks so very much, hierarchy looks excellent. The only thing holding up updating the property definitions on the code systems is when I can I turn Dave T loose on it and he can commit and push without the four of us tripping over each other. If we are good to go now, then I'll tell him he's good to pull to synch then regenerate the resources for the properties. That having been said...part of the reason that they are not properly defined is that I don't have the ability to update the FHIR code system of properties. If, once we create the URLs that don't find the missing codes we can semi-automatically create the proper definitions, then great. Otherwise, please let me know what I need to do to make it happen - ie each of the entries in that code system I can create if you like then you or someone else (Lloyd? Rob H?) can update the code system with the additions. Please let me know how you would like me to proceed.
Grahame Grieve (Dec 12 2019 at 02:18):
sure good to go now
Grahame Grieve (Dec 12 2019 at 02:18):
there's no formal FHIR code system of properties. We need to define one, but that means that for now, we can just discuss them here and then use them
Grahame Grieve (Dec 12 2019 at 02:19):
we should start with a list of all the properties UTG is using, and discuss them
Ted Klein (Dec 12 2019 at 02:20):
the other item - many of the UTG objects - maybe most if not all of them - have <title> as well as <name>. On the FHIR terminologies pages, <title> is being rendered in the table of the code system or value set 'Summary' metadata at the top of each page, but that row in those display grids is missing in the UTG rendered pages
Ted Klein (Dec 12 2019 at 02:21):
OK, let me get together a list and we can figure a time to discuss for sure. I guess the properties are just defined on the page of properties then with the anchor links in the URLs...sigh...no worries...but we do need to discuss them and figure the most efficient way to create the entries.
Ted Klein (Dec 12 2019 at 02:22):
almost bedtime here so I will do that tomorrow
Ted Klein (Dec 12 2019 at 02:23):
one other question: if I want to run a build locally (like I have been doing) did you update the jar file?
Grahame Grieve (Dec 12 2019 at 02:31):
so, say, thie page:
Grahame Grieve (Dec 12 2019 at 02:31):
http://build.fhir.org/ig/HL7/UTG/branches/master/CodeSystem-v3-EntityStatus.html
Grahame Grieve (Dec 12 2019 at 02:31):
doesn't have title in the table at the top?
Grahame Grieve (Dec 12 2019 at 02:31):
yes the ci-build uses the publisher from here:
Grahame Grieve (Dec 12 2019 at 02:31):
https://fhir.github.io/latest-ig-publisher/org.hl7.fhir.publisher.jar
Grahame Grieve (Dec 12 2019 at 02:36):
ok title will be present next release
Ted Klein (Dec 12 2019 at 02:40):
correct - on the rendered pages I can see:
Ted Klein (Dec 12 2019 at 02:40):
EntityStatus
Summary
Defining URL: http://terminology.hl7.org/CodeSystem/v3-EntityStatus
Version: 0.0.3
Name: EntityStatus
Status: All the concepts defined by the code system are included in the code system resource
Definition:
Codes representing the defined possible states of an Entity, as defined by the Entity class state machine.
Publisher: HL7 International - Vocabulary Work Group
OID: 2.16.840.1.113883.5.1061(for OID based terminology systems)
Source Resource: XML / JSON / Turtle
This Code system is referenced in the content logical definition of the following value sets:
Ted Klein (Dec 12 2019 at 02:40):
I will grab a new version of the jar file for my local environment
Ted Klein (Dec 12 2019 at 02:41):
am I not correct that our properties need to be added to: 4.3.14.243 Code System http://hl7.org/fhir/concept-properties
Ted Klein (Dec 12 2019 at 02:41):
??
Grahame Grieve (Dec 12 2019 at 02:42):
they will have to be, yes, but we don't have to do that first
Ted Klein (Dec 12 2019 at 02:47):
ok. I have already got the gang that is developing the import operations for V2, V3, and FHIR External CS working on getting a list of properties. Should have that in the next day or two at most. I'm sorry but I am still unclear as to what we need to do. We went ahead and referred to a code system of properties which does not actually exist as we were waiting to be told what it had to be LOL.
Grahame Grieve (Dec 12 2019 at 02:48):
well, but you didn't give them URLs, just used codes
Ted Klein (Dec 12 2019 at 16:02):
So the basic issue my good man, is that I have NO CLUE what the URL should be. Does it have to have an anchor link the code system of concept properties page? We have defined our own concept properties code system as part of UTG infrastructure at http://terminology.hl7.org/CodeSystem/hl7-terminology-concept-properties. I think from something I saw somewhere, but cannot locate it again now, it should be: http://terminology.hl7.org/CodeSystem/hl7-terminology-concept-properties#propertycodevalue. Is this right, or am I still confused?
Grahame Grieve (Dec 16 2019 at 03:11):
http://terminology.hl7.org/CodeSystem/hl7-terminology-concept-properties is ok unless the concept is already in the FHIR spec defined concept property, but we should probably stick to defining these things in the one place, which means in the spec. At least re-used ones. MIF identifier, for instance, isn't going to be reused, so who cares?
but let's start with the list...
Ted Klein (Dec 16 2019 at 22:11):
Yes, the idea was to have all of the extra properties that UTG needs to support the old legacy V3 coremif content and the V2 table content in such a separate code system for UTG, and not muddy the FHIR waters with it all. I will upload the excel file with the current properties; the columns should be self explanatory.
Ted Klein (Dec 16 2019 at 22:12):
Ted Klein (Dec 16 2019 at 22:24):
There is what I believe to be the full list.
Grahame Grieve (Dec 16 2019 at 22:25):
it's longer than I expected. ok, I went through and for each property, marked whether or not I think it's of general interest outside UTG:
Grahame Grieve (Dec 16 2019 at 22:25):
Grahame Grieve (Dec 16 2019 at 22:26):
if a property is of general interest, we should create it in the base specification code system. If it's not, we should define a it in a special UTG code system
Ted Klein (Dec 16 2019 at 22:27):
Agreed. We just never could get the discussion until now.
Ted Klein (Dec 16 2019 at 22:29):
if we put the code system hl7-terminology-concept properties in UTG (with all the rest of the code systems at terminology.hl7.org) and set the URL to that, does that work for you? (after we clean it up, remove the ones you want in the general, and implement them in the FHIR general list)
Grahame Grieve (Dec 16 2019 at 22:30):
maybe. Do you want to review my added column first?
Grahame Grieve (Dec 16 2019 at 22:30):
I'm not sure about ComponentOf - where is that used?
Ted Klein (Dec 16 2019 at 22:32):
I do want too review it. I suspect some of the properties were not implemented as they should be. ComponentOf is a relationship type; methinks that perhaps all of the ones that are relationship types (a half dozen or more) want to be examined as to how they are implemented in UTG.
Grahame Grieve (Dec 16 2019 at 22:33):
well, the other one I saw was subsumedBy, which we already agreed to make 'parent'.
Grahame Grieve (Dec 16 2019 at 22:33):
the others are auxillary relatonships which have to be properties (I thought)
Ted Klein (Dec 16 2019 at 22:35):
yes that is right.. The code systems is ActRelationshipType. If I was reimplementing all of this fresh, there would be a map holding this stuff, but we did it with properties in V3. The full definition of one of the codes in there that uses this property is:
Ted Klein (Dec 16 2019 at 22:35):
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>The target act is a component of the source act, with no semantics regarding composition or aggregation implied.</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="Specializes">
<targetConcept code="ART"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10318"/>
<conceptProperty name="conductible" value="false"/>
<conceptProperty name="isDocumentCharacteristic" value="false"/>
<conceptProperty name="Name:Act:inboundRelationship:ActRelationship" value="componentOf"/>
<conceptProperty name="Name:Act:outboundRelationship:ActRelationship" value="component"/>
<conceptProperty name="Sort:Act:inboundRelationship:ActRelationship" value="E________"/>
<conceptProperty name="Sort:Act:outboundRelationship:ActRelationship" value="E________"/>
<printName language="en" preferredForLanguage="true" text="has component"/>
<code code="COMP" status="active"/>
</concept>
Ted Klein (Dec 16 2019 at 22:36):
It is used in AddressPartType as well
Grahame Grieve (Dec 16 2019 at 22:36):
which property are we talking about here?
Ted Klein (Dec 16 2019 at 22:36):
ComponentOf. it is odd, since it is both a relationship type, as well as a value for other properties in the formal naming setup
Ted Klein (Dec 16 2019 at 22:37):
e.g.
Ted Klein (Dec 16 2019 at 22:37):
<concept>
<annotations>
<documentation>
<definition>
<text>
<p>This can be a unit designator, such as apartment number, suite number, or floor. There may be several unit designators in an address (e.g., "3rd floor, Appt. 342"). This can also be a designator pointing away from the location, rather than specifying a smaller location within some larger one (e.g., Dutch "t.o." means "opposite to" for house boats located across the street facing houses).</p>
</text>
</definition>
</documentation>
</annotations>
<conceptRelationship relationshipName="ComponentOf">
<targetConcept code="AL"/>
</conceptRelationship>
<conceptProperty name="internalId" value="10651"/>
<printName language="en" preferredForLanguage="true" text="additional locator"/>
<code code="ADL" status="active"/>
</concept>
Grahame Grieve (Dec 16 2019 at 22:38):
that definition is odd. It specializes ART - what's that? And it's a component of... what?
Grahame Grieve (Dec 16 2019 at 22:38):
I understand the use of ComponentOf in Address there - it seems like something very different
Ted Klein (Dec 16 2019 at 22:39):
now you are at the limit of my understanding of what the V3 folks did in the original design. Lloyd may remember; this was hashed out with Woody almost 20 years ago.
Ted Klein (Dec 16 2019 at 22:40):
the address one though seems straightforward
Ted Klein (Dec 16 2019 at 22:41):
ADL is a component of AL, which is Address Locator
Ted Klein (Dec 16 2019 at 22:42):
I am pretty clueless about the whole formal naming implementation, and how it is used in the generation of the V3 ballots is completely unknown to me
Grahame Grieve (Dec 16 2019 at 22:42):
@Lloyd McKenzie
btw I dont' think the UTG expression of address part type is actually correct. The whole code system has a part-of relationship, and it's not a poly-heirarchy. So it should be a case of hierarchyMeaning = part-of, and a single heirarchy. Instead, it has a heirarchy with no defined meaning, and part-of relationships as well
Ted Klein (Dec 16 2019 at 22:43):
aha. OK, that needs to go on the list of stuff to be debugged/fixed. I think that it may be the case that all of the code systems in v3 that have a single hierarchy which is not 'is-a' are implemented wrongly in this way.
Grahame Grieve (Dec 16 2019 at 22:44):
there's others? I thought that was the only one?
Grahame Grieve (Dec 16 2019 at 22:44):
it's the only one using ComponentOf
Grahame Grieve (Dec 16 2019 at 22:44):
other than the weird act relationship thing where componentof is the value of the property rather than the code for the property
Ted Klein (Dec 16 2019 at 22:44):
I think there are other ones that use different relationship types. needs research
Ted Klein (Dec 16 2019 at 22:48):
I'll need to search for ConceptRelationship relationshipName=" and remove duplicates from the result set. there may not be that many after all. But there I a lot of accumulated baggage in the V3 material.
Ted Klein (Dec 16 2019 at 22:53):
OK, not so bad. I think all if these are in our list already as properties:
Ted Klein (Dec 16 2019 at 22:53):
ClassifiesClassCode
componentOf
hasSubtype
mayBeQualifiedBy
owningAffiliate
owningSection
owningSubSection
smallerThan
Grahame Grieve (Dec 16 2019 at 22:54):
hasSubtype is not in the spreadsheet
Ted Klein (Dec 16 2019 at 22:55):
that is the one we modeled using subsumedBy
Ted Klein (Dec 16 2019 at 22:56):
I can find all the code systems these are used in...
Ted Klein (Dec 16 2019 at 22:59):
ROTFL. we can toss the hasSubtype; it is only used in a deprecated code system with all the data removed except a note "Do Not Use". LOL
Ted Klein (Dec 16 2019 at 22:59):
probably why we never built it into UTG two years ago when the first import was a done
Grahame Grieve (Dec 16 2019 at 23:01):
ok. so you agree with my list?
Ted Klein (Dec 16 2019 at 23:02):
oh wait, it is used in...drum roll...MediaType!
Ted Klein (Dec 16 2019 at 23:02):
looking, was sidetracked hunting down those strange relationship types
Grahame Grieve (Dec 16 2019 at 23:02):
hasSubype is used in MediaType?
Grahame Grieve (Dec 16 2019 at 23:04):
if so, didn't make it into UtG source of truth
Ted Klein (Dec 16 2019 at 23:06):
I do...almost. The listed v2 properties are used ONLY in the single code system v2-tables.xml which models the tables as concept does with a much of metadata. This is so specialized, I don't see a good reason to move these into the general set.
Ted Klein (Dec 16 2019 at 23:06):
correct. looking to see what was done and why it is not there.
Grahame Grieve (Dec 16 2019 at 23:06):
I thought 2 from taht set - status and comment.
Ted Klein (Dec 16 2019 at 23:08):
so...table comment is used only in this special place. Deprecated I think is general, as it is distinct from Active (but arguments could be made it is just a flavor of Active, so becomes just an additional status code)
Ted Klein (Dec 16 2019 at 23:09):
you marked deprecated not status LOL
Grahame Grieve (Dec 16 2019 at 23:09):
right whether statyus or something else, deprecated is a general purpose thing
Ted Klein (Dec 16 2019 at 23:09):
but I get the drift
Grahame Grieve (Dec 16 2019 at 23:09):
oh yes. status. oops
Ted Klein (Dec 16 2019 at 23:10):
yes these probably should not be distinct...just makes the reimport back into the v2 publishing tools require a bit more cleverness
Grahame Grieve (Dec 16 2019 at 23:10):
oh - no, not whoops. Is the status of the table the same as the status of the concept?
Ted Klein (Dec 16 2019 at 23:10):
they are distinct in the v2 publishing database
Ted Klein (Dec 16 2019 at 23:11):
it is not. hence the need for a special property
Grahame Grieve (Dec 16 2019 at 23:11):
then I was right, and it's not a general purpose concept
Ted Klein (Dec 16 2019 at 23:11):
concept might still be active although the table has been removed from the current publication. these are mostly publishing control items, hence my sense they are not general
Ted Klein (Dec 16 2019 at 23:12):
the deprecated on the table has the special V2 publishing meaning of deprecated (formal definition in the conformance chapter of v2)
Grahame Grieve (Dec 16 2019 at 23:13):
ok. so a special purpose concept too.
Ted Klein (Dec 16 2019 at 23:13):
but I can be convinced that deprecated is sufficiently general
Ted Klein (Dec 16 2019 at 23:13):
all this baggage in v2-tables.xml is special purpose since tables are not a popper vocabulary object in the current hl7 vocabulary model
Ted Klein (Dec 16 2019 at 23:13):
proper
Ted Klein (Dec 16 2019 at 23:15):
status and deprecated are both sprinkled throughout the rest of the v2 code systems, the others not
Ted Klein (Dec 16 2019 at 23:16):
all the v3 ones I agree with you
Lloyd McKenzie (Dec 17 2019 at 00:01):
What exactly is the question around partOf in addresses?
Grahame Grieve (Dec 17 2019 at 00:05):
I think the UTG representation is wrong
Lloyd McKenzie (Dec 17 2019 at 00:25):
Why? It's reflecting specialization correctly. It's not exposing the 'part' relationship because it's a terminology that includes both 'is a' and 'part of' relationships, so we use the default for hierarchy, which is 'is a'.
Grahame Grieve (Dec 17 2019 at 00:32):
it does not include is-a relationships, at least, it should not.
Lloyd McKenzie (Dec 17 2019 at 01:05):
Why? They're part of the terminology. A "delivery address line" is an "address line" - it's a not a "part of" relationship.
Grahame Grieve (Dec 17 2019 at 01:14):
sigh. this is pointless complexity. really. No one cares. But if we really have to do complexity like this, we should really do it properly, and at least fill out the hierarchyMeaning
Lloyd McKenzie (Dec 17 2019 at 04:06):
HierarchMeaning is subsumption and there's an additional set of relationships for the partOf bit (because we have mechanisms to capture additional partOf relationships, but I don't think we have a way to capture additional subsumption relationships of the hierarchyMeaning was partative).
Grahame Grieve (Dec 17 2019 at 04:18):
HierarchMeaning is subsumption
that's not stated
Lloyd McKenzie (Dec 17 2019 at 14:52):
Ah, well then I agree that's a problem.
Ted Klein (Dec 18 2019 at 03:22):
Yes this should be fixed
Grahame Grieve (Dec 18 2019 at 03:29):
what's the timeline here?
Ted Klein (Dec 18 2019 at 03:32):
As soon as I can get my local build working (it is still failing on 1.0.25) then I will update content and rebuild the resources and verify then push. I was hoping today, but maybe tomorrow...but the jury is still out on what the problem with my local build is (same content and same jar file works on Lloyd's windows env and Rob H's Mac environment but fails with an NPE on my content load). So...this week absolutely we need to get this stuff addressed (rebuild the resource and fix the URL for the property definitions).
Grahame Grieve (Dec 18 2019 at 03:33):
you have a space in the path?
Grahame Grieve (Dec 18 2019 at 04:58):
Grahame Grieve (Dec 18 2019 at 04:59):
ok I filled out the proposed properties. If we can agree, then I'll commit the appropriate changes to define these formally to both build.fhir.org and the UTG source
Grahame Grieve (Dec 18 2019 at 05:00):
btw, we should ensure that all UTG CodeSystems have an explicit hierarchyMeaning. I presume we will always populate it with "subsumption"
Rob Hausam (Dec 18 2019 at 05:04):
I suppose there's not an intrinsic reason that we couldn't define a code system that is in UTG as a classification (or one of the others)
but I don't believe that we have (or likely will), so agree they would be "is-a" (i.e. subsumption)
Grahame Grieve (Dec 18 2019 at 05:05):
when and if we start defining classifications, then we should change the rule. but this doesn't seem likely right now
Rob Hausam (Dec 18 2019 at 05:06):
yes, agree
Ted Klein (Dec 18 2019 at 10:14):
I'm happy to have this simplemented today - all code systems with any hierarchy having an explicit value in there.
Ted Klein (Dec 18 2019 at 10:17):
The properties you have listed there are good. Did you say you would build the tug code system as well and commit it? Or do you need me to do that?
Grahame Grieve (Dec 18 2019 at 10:21):
I'll do it
Carol Macumber (Dec 18 2019 at 16:03):
(deleted)
Carol Macumber (Dec 18 2019 at 16:04):
Agreed, assuming that this code system defining classifications won't be part of FHIR Core, rather a UTG codesystem so that it isn't tied to a ballot
Grahame Grieve (Dec 18 2019 at 19:17):
I can't think how we could design a classification that was useful and met the requirements for something is in FHIR core rather than UTG
Grahame Grieve (Jan 22 2020 at 04:05):
ok I just released a new toolkit - this is version 60, and should work on both windows and OSX
Grahame Grieve (Jan 22 2020 at 04:06):
including namingsystem editing, which works for me
Jessica Bota (Jan 22 2020 at 20:50):
@Grahame Grieve , that is great, thank you. I installed and checked out the Naming system creation / editing functionality and it seems to be working well.
Jessica Bota (Jan 22 2020 at 20:52):
I am still getting the same errors connecting the R4 toolkit to the vocab server. I sent over the steps to reproduce that error a few weeks ago, but would be happy to meet and show you what I am seeing. I can be available for your morning.
Grahame Grieve (Feb 01 2020 at 22:07):
@Ted Klein @Robert McClure The current toolkit release is http://www.healthintersections.com.au/FhirServer/fhir-toolkit-osx-0.0.63.zip. it works fine on MacOS Mojave, but not at all on Catalina. We are investigating the problem
Grahame Grieve (Feb 02 2020 at 04:31):
well, now Chrome has decided to block downloads altogether...
Grahame Grieve (Feb 02 2020 at 04:31):
other browsers do not have an issue
Ted Klein (Feb 02 2020 at 06:28):
Gotta love this third party technology...sigh...thanks for getting the Mojave version working. I am holding off upgrading to Catalina for the foreseeable future for other reasons as well. I'll mess with this tomorrow. Thanks for getting the issues sorted (hopefully).
Last updated: Apr 12 2022 at 19:14 UTC
