search

intervention-engine / fhir

Generic FHIR server implementation in GoLang.
Apache License 2.0
111 stars 51 forks source link

Inheritance of Resource, DomainResource, Element and BackboneElement #26

Open Waitak opened 8 years ago

Waitak commented 8 years ago

In the XML Schema Resource, DomainResource, Element and BackboneElement are parent types of most of the data and resource types. In particular, they include fields like Language and Extension. These seem to be absent from the various classes, or am I missing something?

cmoesel commented 8 years ago

You are correct -- the current code in master does not reflect the properties of any of these base resources or elements (except for id). I recently submitted a pull request (#25) that addresses some of this by having resources properly inherit from DomainResource (and DomainResource inherits from Resource). One of my colleagues is reviewing the PR and will likely merge it soon. This will get you all of the basic goodies on resources (id, meta, extension, etc).

We don't yet have a plan, however, for support of BackboneElement and/or Element. This means that non-resource elements (e.g., primitive types) can't have ids or extensions. To be honest, it's one of those things we've been hesitant to implement because we really don't like the idea of extending primitives (it pretty much defeats the normal notion of what a primitive is). It's not needed by our main use case, and I think we've been hoping it would be voted out of the spec. ;-) That said, if it's here to stay, we probably need to think more seriously about it -- but it does make implementation much more clunky (sigh). Is this something that will prohibit you from using and/or contributing to this project?

Waitak commented 8 years ago

Well, I make regular use of the language element, which is defined at the parent class level. I can do without the internal ID, which is the other main contribution, but language is a gotta-have for my use case.

cmoesel commented 8 years ago

Support for the base DomainResource and Resource classes was added in PR #25, which has now been merged to master. So... language shouldn't be a problem anymore. Does that resolve your main concerns?

Waitak commented 8 years ago

That's great, thank you. What are the plans for implementing CodeSystem?

cmoesel commented 8 years ago

I'm not entirely sure what you mean by "implementing CodeSystem" -- could you provide a few more details? CodeSystem isn't a resource, but the ValueSet resource defines a CodeSystem component for defining code systems inline. Is that what you're talking about? (If so, our model supports that already).

Waitak commented 8 years ago

CodeSystem is now a resource, actually: http://hl7-fhir.github.io/codesystem.html The plan (since Orlando) is to move all code systems out of value sets and into their own, separate resource. It's quite a major change.

cmoesel commented 8 years ago

Oh. I see. This wasn't on my radar, as we've been focused on DSTU2. Right now, we remain focused on DSTU2, so I wouldn't expect to see support for CodeSystem until closer to DSTU3.

That said, much of our code is generated from the FHIR tool chain, so it may be possible to rebase our code generation on a later version of the FHIR sources and generate out the latest (DSTU3) resources (assuming the tool chain itself hasn't changed a lot) -- but that would require forks of our fhir and fhir-golang-generator projects -- and maintaining those forks while we continue to work on the master branches. If this is something you're truly interested in, let me know and we can throw you a few pointers.

Waitak commented 8 years ago

I am, thank you. Might a different channel be better to chat about it? IRC? Email? Skype?