Stream: hapi
Topic: Reference Implementation
Keith Boone (Jun 10 2016 at 04:37):
I'm writing a tool that takes mappings I put in the the mapping column for a profile, and turns the resulting profile into a transformer that generates a FHIR Resource from the mapped source material. One of the challenges I'm having is all the vagaries of how the RI works.
Keith Boone (Jun 10 2016 at 04:40):
When a field is polymorphic in the RI, it has a setFieldname() signature. When a field is typed, there is a setFieldnameType() signature. I would expect for polymorphic fields to see setFieldname(Type x) to work as specified, and setFieldnameSpecifictype(SpecificType x) to also exist. It's frustrating that it doesn't because it means I have to put conditions in to check for polymorphism IN the base class, which model I really didn't want to have to read if I could skip it.
Keith Boone (Jun 10 2016 at 04:40):
Oh, I'm working with DSTU2 BTW, not DSTU3.
Keith Boone (Jun 10 2016 at 04:54):
Another challenge is dealing with the enumeration types when the base type is code. I understand why this was done, but the problem is that I have no consistent way to figure out whether the enumeration is defined WITHIN the resource or separately (e.g., compare AdministrativeGender with ObservationStatus, nor when I have to be sure that the enumeration is used rather than the codeType. What I really want is a setXElement(CodeType t) method for these fields that is permitted to thrown an exception is CodeType is not a legal value.
Grahame Grieve (Jun 10 2016 at 05:42):
there's no need to clutter up the interface with setFooType methods, since they all do the same thing
Grahame Grieve (Jun 10 2016 at 05:43):
and clutter is the relevant word
Grahame Grieve (Jun 10 2016 at 05:43):
you can easily check the polymorphism by looking at the base path
Grahame Grieve (Jun 10 2016 at 05:43):
I know that's not as easy as ignoring it, but it shouldn't be hard
Keith Boone (Jun 10 2016 at 05:47):
I could live with that one by simply extending the types and adding the polymorphic methods myself too, so I can live with that either way.
Keith Boone (Jun 10 2016 at 05:48):
However, the problem with code is truly challenging. How in the heck do I figure out where the enumeration is defined or if it is even used. The RI apparently has some rules about when those are used and when they are not, but I cannot figure them out.
Grahame Grieve (Jun 10 2016 at 05:50):
well, if the code has a required value set binding, then it will get an enumeration
Keith Boone (Jun 10 2016 at 05:50):
Nope.
Grahame Grieve (Jun 10 2016 at 05:50):
if the required value set binding is shared across more than one place, it will be in Enumerations, else it will be in the resource
Keith Boone (Jun 10 2016 at 05:50):
I thought that was the case, but apparently it is not as far as I can tell.
Grahame Grieve (Jun 10 2016 at 05:51):
it should be the case
Keith Boone (Jun 10 2016 at 05:51):
I'll dig up my example for that one.
Keith Boone (Jun 10 2016 at 05:51):
On the Enumerations case, the information about whether the value-set is used in more than one place is NOT included in the structure definition for the value set. I have to read the whole freakin FHIR model to figure that out.
Grahame Grieve (Jun 10 2016 at 05:52):
yes, that's not very friendly. I'm thinking about that
Keith Boone (Jun 10 2016 at 05:52):
I could maybe parse the HTML page but that's a hack. I might have to resort to it.
Grahame Grieve (Jun 10 2016 at 05:52):
in other languages, I can alias these things, but it's not so easy in java
Grahame Grieve (Jun 10 2016 at 05:52):
parse html? why do that?
Keith Boone (Jun 10 2016 at 05:55):
To get to the "is it used in more than one place" data.
Keith Boone (Jun 10 2016 at 05:55):
Only place I see it in the output.
Keith Boone (Jun 10 2016 at 05:55):
Althought arguably, the build could add that data to the .json and .xml defs as an extension.
Grahame Grieve (Jun 10 2016 at 05:56):
I could. no one has asked for it before
Grahame Grieve (Jun 10 2016 at 05:57):
it sounds more like something that belongs in the java space though, since it's specific to the Java RI
Keith Boone (Jun 10 2016 at 05:57):
On the aliasing, you COULD provide Patient.AdministrativeGender class that supported the fromCode() method.
Keith Boone (Jun 10 2016 at 05:57):
Not really.
Grahame Grieve (Jun 10 2016 at 05:58):
if I provide a Patient.AdministrativeGender, I'd break lots of code because I'm not providing a common class for the common usages
Keith Boone (Jun 10 2016 at 05:58):
I'm reading the .json to generate Java code. I DON'T want to have to read the Java RI model. I want some simple rules to go from the structureDef's to the Java. Or I want the rules that do exist to be documented somewhere.
Keith Boone (Jun 10 2016 at 05:58):
Huh?
Grahame Grieve (Jun 10 2016 at 05:59):
that doesn't change the fact that this is specific to the Java RI
Grahame Grieve (Jun 10 2016 at 05:59):
there is a solution, actually, which is to generate getFooCode / setFooCode for enumerations, as well as the 2 existing pairs of accessors
Keith Boone (Jun 10 2016 at 06:01):
Yes, which was what I asked for above, but called it setFooElement instead. That would work.
Grahame Grieve (Jun 10 2016 at 06:02):
but that already exists
Grahame Grieve (Jun 10 2016 at 06:02):
ah but not with the type you want
Keith Boone (Jun 10 2016 at 06:03):
Right.
Keith Boone (Jun 10 2016 at 06:03):
I'd be fine with setFooCode, because the name difference also deals with the behavioral difference. One throws an exception, the other does not.
Keith Boone (Jun 10 2016 at 06:04):
Do other RI's locally define the enumeration unless it is shared?
Grahame Grieve (Jun 10 2016 at 06:05):
I'll start by putting it in the DSTU3 version for non-repeating enumerations.
Grahame Grieve (Jun 10 2016 at 06:05):
other RIs work very differently depending on the language
Brian Postlethwaite (Jun 10 2016 at 06:07):
The dotnet client implementation also generates the enumerations using the same rules.
And yes, I do parse the entire XML (profile-datatypes and profile-resource) to determine if it is used elsehwere (simple XSLT usage) to work out where to put the enumeration class.
Keith Boone (Jun 10 2016 at 06:10):
Immunization.setStatus(String), Immunization.setStatusElement(CodeType)
Keith Boone (Jun 10 2016 at 06:10):
doesn't follow the "required" rule.
Keith Boone (Jun 10 2016 at 06:12):
Brian, I'm parsing 2-3 files now. I don't really want to have to parse everything. It's already taking me an hour just to build my profiles. If I had to read everything to understand the RI model, it would be a lot more complicated.
Grahame Grieve (Jun 10 2016 at 06:13):
Brian is referring to building the RI
Keith Boone (Jun 10 2016 at 06:15):
Given that valueset-*.html has the data about where a value set is used, it's pretty clear that valueset-*.json could have an extension that said "used in multiple places".
Brian Postlethwaite (Jun 10 2016 at 06:15):
(yes, for the dotnet RI)
Brian Postlethwaite (Jun 10 2016 at 06:18):
FYI, the dotnet RI is completely generated from 4 files (profiles-resources.xml, profiles-types.xml, search-parameters.xml and expansions.xml)
Grahame Grieve (Jun 10 2016 at 06:19):
but you don't need that if I generate the setFooCoode methods...?
James Agnew (Jun 10 2016 at 10:13):
I'm not getting how these getFooCode() methods would help. The existing methods follow the same pattern as all the other primitive fields:
getFoo()returns the native type (an Enum, a Date, a String, etc..)getFooElement()returns the FHIR type (Enumeration, DateType, etc)
On the DSTU2 structures there is the matter of the signatures being a bit less predictable with when they throw exceptions, as Kieth points out, but that's already resolved in the DSTU3 ones. Is this just a DSTU2 issue?
James Agnew (Jun 10 2016 at 10:13):
Of course I'm using Patient.gender as my reference point. Is there another field where the problem is more apparent?
Grahame Grieve (Jun 10 2016 at 10:15):
the AsCode() methods always return a string. The existing native codes return either a code or an enumeration, and the namespece of the enumeration is uncertain.
Grahame Grieve (Jun 10 2016 at 10:15):
exposing the string code directly makes sense to me
James Agnew (Jun 10 2016 at 10:16):
So the issue is wanting a predictable way of getting the string value of the code?
Wouldn't getFooElement().getValueAsString() accomplish this?
Grahame Grieve (Jun 10 2016 at 10:17):
what does it return if there's no foo?
James Agnew (Jun 10 2016 at 10:17):
null
James Agnew (Jun 10 2016 at 10:17):
(Not a NPE though, just returns null)
Grahame Grieve (Jun 10 2016 at 10:17):
and how does the set work? set null to make foo go away?
James Agnew (Jun 10 2016 at 10:18):
getFooElement().setValueAsString(null); would accomplish that
Grahame Grieve (Jun 10 2016 at 10:18):
so........ I think that works for Keith. I should have thought of that
Keith Boone (Jun 10 2016 at 19:09):
Right, but that's only going to work for DSTU3... and I have DSTU2 to consider as well.
Keith Boone (Jun 10 2016 at 19:15):
Hunh, that looks look it might work.
Keith Boone (Jun 10 2016 at 20:48):
@James Agnew Thanks! That solved it for me.
Last updated: Apr 12 2022 at 19:14 UTC
