Stream: fmg
Topic: 6/8 FMG Call
Anne Wizauer (Jun 07 2016 at 21:44):
Hi all - I am unfortunately going to have to be out of the office tomorrow. Somehow you'll survive without me!
Draft agenda here: http://wiki.hl7.org/index.php?title=20160608_FMG_concall#Agenda
Josh Mandel (Jun 08 2016 at 16:19):
I can attend today's call but 20-30 min late (I have a partial conflict).
Josh Mandel (Jun 08 2016 at 21:12):
So I missed the first 25 minutes - but I've been perplexed for the last 45. Are we trying to approve a PSS or design a solution here?
Grahame Grieve (Jun 08 2016 at 21:21):
resolve a committee argument
Josh Mandel (Jun 08 2016 at 21:22):
Ah
Josh Mandel (Jun 08 2016 at 21:22):
Thanks!
Anne Wizauer (Jun 10 2016 at 21:34):
Hi all - did anyone take minutes?
Lloyd McKenzie (Jun 10 2016 at 22:25):
Yes. Will try to get them transcribed this weekend. (Nowhere close to the quality of yours though.)
Grahame Grieve (Jun 14 2016 at 00:14):
all: I would like to get this signed off by FMG this week:
http://wiki.hl7.org/index.php?title=FHIR_Custom_Resources
Grahame Grieve (Jun 14 2016 at 00:15):
if people can consider it and discuss it in advance, it might be a short item...
Brian Postlethwaite (Jun 14 2016 at 12:02):
Reviewing the Custom Resources Policy page, there is no note on the Basic resource, just to say that this is not describing, or replacing use of the conformance basic extensions.
Brian Postlethwaite (Jun 14 2016 at 12:02):
Otherwise, I'm happy with it as is.
David Hay (Jun 14 2016 at 20:03):
Will be interesting to see how this plays out in practice (and I do have some concerns), but happy to support it...
Grahame Grieve (Jun 14 2016 at 23:02):
ok I added a section about Basic. You can check it please @Brian Postlethwaite
Brian Postlethwaite (Jun 14 2016 at 23:04):
Looks ok, didn't think nested extensions were that bad to go out of your way to advise against (kind-of).
Grahame Grieve (Jun 14 2016 at 23:06):
well I wasn't recommending against nested extensions per se, just that that's about the point to think about using custom resources instead of basic
David Hay (Jun 14 2016 at 23:45):
but only if the resource you want to build has no overlap with an 'official' resource - eg one of the examples we used in early days was an extension on Patient indicating that patient was enrolled in a clinical trial and you wanted to record date enrolled, programme name & other info. The 'nested' extension was a tidier solution than separate ones...
Grahame Grieve (Jun 14 2016 at 23:56):
of course. Nested extensions are good and useful and important. This is not about nested extensions
Lloyd McKenzie (Jun 15 2016 at 00:10):
Have we thought about having a mandatory extension on the custom resources that points to the IG defining the resource with a rule similar to extensions that the resource definition must be available to receiving instances just as an extension definition is? That would, in theory, allow implementations to process instances with custom resources in a semi-transparent way. (We could build code into the reference implementations that would treat custom resources as special 'Basic' implementations or something.) That would at least reduce the partitioning of the space to "not significantly worse" than Basic.
Grahame Grieve (Jun 15 2016 at 00:13):
well, we could. But I'd rather do it out of band: for any registration of an custom name or prefix, we require the address of the registry to be declared. And we publish the registry as part of the formal processible list of approved names and prefixes (at http://fhir.org/custom-resources.json). Then, a processor can find the definition if it wants to
Grahame Grieve (Jun 15 2016 at 00:13):
(and has rights to)
Lloyd McKenzie (Jun 15 2016 at 00:19):
How does that work with prefixes? I didn't see anything about submitting the IG to an HL7 maintained registry in the documentation as a pre-requisite for conformance. (And it might freak out the DND and other folks who want their stuff behind a firewall.)
Grahame Grieve (Jun 15 2016 at 00:28):
they nominate their registry. They control access to their registry. No need for freak outs
Brian Postlethwaite (Jun 15 2016 at 00:29):
DoD not DND?
Lloyd McKenzie (Jun 15 2016 at 01:01):
I don't see anything listed in the document about a requirement to specify the address of the registry where it'll be defined. Nor the conformance requirement that the registry must be available to anyone receiving instances containing the resource.
Grahame Grieve (Jun 15 2016 at 01:02):
I proposed that above as an addition to the document. I don't think that we should say that the registry must be available - if it's not, then you fail.
Lloyd McKenzie (Jun 15 2016 at 01:04):
I think the rules should be the same as for extensions. If the registry goes down, that's not an issue. But if you don't have permission to access the registry, the system that sent you the instance is non-conformant
Grahame Grieve (Jun 15 2016 at 01:06):
well, how about SHOULD be accessible, no SHALL be.
Lloyd McKenzie (Jun 15 2016 at 01:59):
Isn't the rule for extensions "SHALL"?
Grahame Grieve (Jun 15 2016 at 02:13):
yes. it is. And yes, I'm proposing a lesser rule here.
Lloyd McKenzie (Jun 15 2016 at 13:57):
What's the justification for the rule being less strong?
Lloyd McKenzie (Jun 15 2016 at 13:57):
I don't think it's significantly harder on the implementer for the rule to be the same
Josh Mandel (Jun 15 2016 at 14:31):
As part of this policy then, it is explicitly noted that doing this is not a conformant use of the FHIR specification, and will not be made conformant.
How can you tell? Is this just a smell test? Whose nose?
Josh Mandel (Jun 15 2016 at 14:32):
Applicants may apply for a custom name, or for a prefix
Are we saying the name-space and the prefix-space overlap? So if someone has a resource named "smart-home-control-panel" then I can no longer register a prefix of "smart-"?
Josh Mandel (Jun 15 2016 at 14:32):
Also... "How custom resources work, technically" doesn't really deliver on the promise: I don't know how to *use* them in a real setting. What is a server expected to do if it sees one, etc.
Grahame Grieve (Jun 15 2016 at 19:38):
"how can you tell" - indeed, there is no simple test
Grahame Grieve (Jun 15 2016 at 19:39):
and yes, the spaces overlap, so name issuance has to be done with that in mind
Grahame Grieve (Jun 15 2016 at 19:39):
and I don't know what 'use' means. You use them like any other resource.
Josh Mandel (Jun 15 2016 at 20:04):
Joining shortly -- caught in a work meeting 5min more
Josh Mandel (Jun 15 2016 at 20:09):
"use" -- if my server hasn't heard of this, what steps should I take when I see one of these resources?
Josh Mandel (Jun 15 2016 at 20:11):
Conformance.rest.resource.type is a fixed valueset; would that change?
Josh Mandel (Jun 15 2016 at 20:11):
(for example)
Grahame Grieve (Jun 15 2016 at 20:12):
well, that's up to your server, but by default, one would expect an error
Grahame Grieve (Jun 15 2016 at 20:12):
there's an open issue around types and closure already, but we'd have to do something about that
Josh Mandel (Jun 15 2016 at 20:16):
And back to the "smell test" : who decides?
Josh Mandel (Jun 15 2016 at 20:17):
Can prefixes be revoked when FHIR expands its core scope?
Josh Mandel (Jun 15 2016 at 20:18):
And I'd be happier with an approach that didn't smash prefixes and custom names into the same name space (just for example, you could force all "one-off" names to start with "ext-" or some such)
Grahame Grieve (Jun 15 2016 at 20:19):
I don't think there's any answer to 'who decides'. You could say that same about how exceptions are used
Grahame Grieve (Jun 15 2016 at 20:20):
I don't think it makes sense to revoke a whole prefix, but it's technically possible, for whatever it would mean to 'revoke'
Grahame Grieve (Jun 15 2016 at 20:21):
and I was taking for granted that there would be some practice around custom names that ensured unqiueness, like, well, 'ext-'
Josh Mandel (Jun 15 2016 at 21:05):
Sorry, I must be misunderstanding something about the "who decides" issue. The writeup says this distinction makes the difference between conformant and non, so it must be up to somebody (or some process) to decide.
Grahame Grieve (Jun 15 2016 at 21:09):
really? it 'must'? why?
Lloyd McKenzie (Jun 15 2016 at 21:09):
My assumption re: prefixes is that prefixes will be crafted in such a way that they can't overlap with regular names. For example, the prefix might be "Smart-", so it wouldn't collide with a name like SmartLink
Grahame Grieve (Jun 15 2016 at 21:10):
it would certainly be good. But we do routinely make conformance rules that are not testable
Josh Mandel (Jun 15 2016 at 21:21):
I don't know about routinely, but it seems very silly here.
Josh Mandel (Jun 15 2016 at 21:22):
For implementers not to know whether or not an implementation was conformant.
Josh Mandel (Jun 15 2016 at 21:33):
Also, are custom Datatypes a requirement? (Or why not?)
Grahame Grieve (Jun 15 2016 at 21:35):
I don't think custom data types are a requirement
Josh Mandel (Jun 15 2016 at 21:36):
Why? If you're openehr for example, you'd want composable types, no?
Grahame Grieve (Jun 15 2016 at 21:36):
no they don't. actually.
Josh Mandel (Jun 15 2016 at 21:37):
But you're not engaging with my *why* question :)
John Moehrke (Jun 15 2016 at 21:40):
I don't understand what a custom resources is.. It is clearly not a resource formally defined in FHIR. FHIR is not the first organzation to define HTTP RESTful resources, so are we saying that custom resources is the set that is not FHIR? And thus all the propritary HTTP RESTful resources that have ever been defined or will ever be defined by anyone other than FHIR?
John Moehrke (Jun 15 2016 at 21:49):
if a resource smells similar to FHIR but isn't; it is just as non-interoperable as if it didn't have anything in common with FHIR other than HTTP REST principle.
John Moehrke (Jun 15 2016 at 21:49):
I do recognize that you have put some constraints on the set, but for argument sake I am arguing that your constraints are immaterial to the discussion, and thus the discussion degrades to the set that is not formally FHIR defined resources.
Paul Knapp (Jun 16 2016 at 07:12):
I think if we allow for prefix separator-character name then:
Prefixes are a uniquely assignable and managed by HL7
Complete resource names for FHIR resources do not and may not contain the separator-character
One or more prefixes are reserved for reserved custom names (eg. 'ext') and HL7 assigns the names for use within those prefixes
All resources which contain a separator-character in their full name are custom
FHIR resources are precluded from refering to custom resources however extensions may
No special requirements on custom resources to point to registries or anything, they are custom.
Grahame Grieve (Jun 16 2016 at 07:18):
Paul, you should read the document. it addresses those things
Grahame Grieve (Jun 16 2016 at 07:19):
well, some of them
Grahame Grieve (Jun 16 2016 at 07:19):
to John's point, of course, anyone can exchange anything. but FHIR custom resources are different than other resources - e.g. SCIM resources
Paul Knapp (Jun 16 2016 at 07:26):
Oh, and all custom resources are non-conformant.
Paul Knapp (Jun 16 2016 at 07:30):
The separator-character can't be '.', if it can be I'd like to formally request registering Patient.id please.
Paul Knapp (Jun 16 2016 at 07:36):
If we want to be able to provide a 'brand' for people who build custom respources following the FHIR design - a limited conformance only to structure not to content- then I think we need a clearly distinquished name, logo, brand for that to reduce misleading and confusion (don't use 'smoke'),
Grahame Grieve (Jun 16 2016 at 08:35):
The main separator character we would deal with is "-". I added "." as a possible for resource name because we'll never use it, and there's some typing systems that might want to use it. But we won't
Grahame Grieve (Jun 16 2016 at 08:36):
if we rule that all custom resources are non-conformant, then we make it very hard for them to be used rightly, and just as easy to be used wrongly. For this reason, I've invested a lot of time in finding a policy that describes a managed use of custom resources that the publis servers and reference implementations can implement, but that limits the non-interoperable outcomes and the blame to HL7.
Grahame Grieve (Jun 16 2016 at 08:37):
I do not agree that simply ruling all use of custom resources non-conformant is a good decision
Grahame Grieve (Jun 16 2016 at 08:38):
as for 'brand' - initially we sought a brand, but the only clue of a brand that emerged that might stick is 'custom FHIR' and an earlier draft used that name - you can claim conformance to custom FHIR.... but an earlier FMG meeting objected to that.
Grahame Grieve (Jun 16 2016 at 08:38):
this whole thing has gone on and now we're starting to go round in circles
Paul Knapp (Jun 16 2016 at 08:41):
I prefer something like conformance to 'FHIR-Structure' or 'FHIR (Structure)' since the content hasn't been put through HL7 processes.
Paul Knapp (Jun 16 2016 at 08:51):
We are not confirming through any of our mechanisms that custom resources conform to anything other than the FHIR structure, right?
If so then FHIR resources conform to FHIR-Structure (and the participants may participant in and have expectations about the FHIR Structure and changes thereto) and to FHIR-Content (the normal domain-managed content development, review and balloting).
John Moehrke (Jun 16 2016 at 12:07):
Grahame, your response to my... how are custom resources 'different' from any http REST resource in the set that is NOT FHIR? You seem to have an understanding of a third set that is neither FHIR, nor not-FHIR; yet you have not explained in what way there are differences or are similarity. You seem to be indicating that this set has some property that makes them as universally standards based as FHIR, yet not defined by FHIR. I simply want more insight to this understanding you have because I lack this knowledge.
Paul Knapp (Jun 16 2016 at 14:36):
John the custom resources would use the same data types and resource definition and structure as FHIR resources, it is just that their existance and content hasn't been review by HL7 domains nor been balloted through HL7 processes.
Paul Knapp (Jun 16 2016 at 14:37):
Other xml and json objects are not FHIR Structure conformant.
John Moehrke (Jun 16 2016 at 19:41):
Paul, that is a nice assumption... but it is a distinction without a difference. FHIR uses 'standard' datatypes for many of the FHIR datatypes. so if I create a resource that uses datatypes of string, time, date, anyURI, etc... does that make my resource a FHIR Custom resource? --- My point is that FHIR has taken great pain to use existing standards, that others also use... so what is the boundary between someone who defined a FooBar resource made up of elements of string, time, date, anyURI.... and a FooBar resource that gets to somehow ride on the marketing coat-tails of FHIR?
John Moehrke (Jun 16 2016 at 19:43):
the fundamental benefit of FHIR is that it is very approachable because it uses off-the-shelf concepts... This is the "F" in FHIR.... so somehow we are defining a 'Custom FHIR' resource that isn't FHIR, but something else. Yet there are billions of existing HTTP RESTful resources that already exist, and an infinite number more yet to come.
Grahame Grieve (Jun 16 2016 at 20:33):
a custom resource is a resource defined using the FHIR conformance resources - StructureDefinition, ValueSet, SearchParameter, and that conforms to all the rules expressed there, and can be used natively on the FHIR RESTful API, or in bundles, just like any other resource. These properties are not true of other resources defined elsewhere. e.g. A SCIM resource - there's a gap between FHIR and SCIM that isn't easily bridged. Same for other restful specifications (you can integrate, but not tightly)
Lloyd McKenzie (Jun 17 2016 at 01:45):
I think it's useful to delineate between systems that are adding "extra" stuff, but are using proper FHIR resources where they apply from systems (and therefore can partially interoperate) from those that aren't trying to interoperate with standard FHIR at all. And I think it's worthwhile and important for us to distinguish those. For that reason, I'm not a big fan of giving out prefixes at all. I'd much prefer that every resource being requested was submitted independently for evaluation against existing resources. I don't think we should call systems that are trying to use standard resources where they can "non-conformant"
Lloyd McKenzie (Jun 17 2016 at 01:46):
Forcing implementers to use Basic is just not reasonable, and forcing someone who has some sort of "extra" requirement to be totally outside the conformance framework even if almost everything they're doing is interoperable isn't reasonable.
John Moehrke (Jun 17 2016 at 12:07):
Grahame, that needs to be said. It is not said on the wiki page. This is the clarity that I seek, now I can use this measuring stick to evaluate if a resource is sufficiently like FHIR to fall into this new 'set'; or doesn't.
John Moehrke (Jun 17 2016 at 12:12):
What is the problem we are trying to solve with the custom resource naming effort? We can only rule over the FHIR domain, and influence the FHIR-Custom domain; while the rest of the http RESTful can name their resources whatever they want. I am sure there are already many different http RESTful defined resources with the name "Patient". All from the pre-FHIR days (and some will yet be made). So within the small space we can absolutely control (FHIR) we have the FMG; so we then have this FHIR-custom space that we want to influence; but why? What problem do we think we can solve? What value do we bring?
John Moehrke (Jun 17 2016 at 12:14):
I understand the prefix solution; I just am not sure the problem has been fully defined so that we can know if the prefix solution solves the problem or simply feels good.
Grahame Grieve (Jun 17 2016 at 12:32):
really, I think it's clear that's what we're talking about. how is the second section not clear?
John Moehrke (Jun 17 2016 at 12:33):
the second section is written as a process one would use to create such a resource. It does not indicate what MUST be true when done.
Grahame Grieve (Jun 17 2016 at 12:34):
well, I thought that was clear, but ok, what wording would you suggest?
John Moehrke (Jun 17 2016 at 12:35):
use the wording you gave me above. declarative.
Grahame Grieve (Jun 17 2016 at 12:38):
well, ok, so read it again
John Moehrke (Jun 17 2016 at 12:47):
why can't you write a section the defines in declarative language what a FHIR-custom resource must conform with using the language you gave: a custom resource is a resource defined using the FHIR conformance resources - StructureDefinition, ValueSet, SearchParameter, and that conforms to all the rules expressed there, and can be used natively on the FHIR RESTful API, or in bundles, just like any other resource. These properties are not true of other resources defined elsewhere. e.g. A SCIM resource - there's a gap between FHIR and SCIM that isn't easily bridged. Same for other restful specifications (you can integrate, but not tightly)
John Moehrke (Jun 17 2016 at 12:48):
ah, refresh problem
John Moehrke (Jun 17 2016 at 12:48):
so, it is still weak wording.... and it is hidden within a paragraph rather than as a H2 definition section.
Grahame Grieve (Jun 17 2016 at 12:49):
what's weak about it?
John Moehrke (Jun 17 2016 at 12:50):
lack of any normative words.
Grahame Grieve (Jun 17 2016 at 12:51):
you want defnition of conformance language? which is it?
John Moehrke (Jun 17 2016 at 12:51):
use of words like 'can be used'.
Grahame Grieve (Jun 17 2016 at 12:52):
can ---> may? but no, that doesn't capture the idea.
Grahame Grieve (Jun 17 2016 at 12:52):
can --> is able
John Moehrke (Jun 17 2016 at 12:52):
you asked... I am just answering. by by using normative words "Shall be defind using StructureDefinition, ValueSet, and SearchParameter", it is much more declarative and measurable.
Grahame Grieve (Jun 17 2016 at 12:52):
?
John Moehrke (Jun 17 2016 at 12:53):
shall conform to what rules? What rules 'can' it choose to not follow?
Grahame Grieve (Jun 17 2016 at 12:53):
nah, I think that's a problem. Definitional see, then you make rules. Is it not a custom resource if you don't define it properly?
John Moehrke (Jun 17 2016 at 12:54):
by what measure is a FHIR-custom resource 'used natively'? vs what is not working natively?>
John Moehrke (Jun 17 2016 at 12:54):
YES, that is exactly my point4
Grahame Grieve (Jun 17 2016 at 12:54):
That's a misnomer. the real thing about custom resources is that you use them in place on the API, or in Bundles, or as the target of a Reference data type
John Moehrke (Jun 17 2016 at 12:55):
by that definition then anyURL is sufficient
John Moehrke (Jun 17 2016 at 12:55):
so SCIM works
Grahame Grieve (Jun 17 2016 at 12:56):
no I did not understand that. You could not use a SCIM resource in place on the API, or in a budnle, or as the target of a Reference
John Moehrke (Jun 17 2016 at 13:06):
then please explain why not? I tried to get declarative language that distinguishes a FHIR-custom from everything else; and you came back saying that it was not that strict.
Grahame Grieve (Jun 17 2016 at 13:08):
I'm not sure how to express why it wouldn't work. but if you tried it, you'd find that it doesn't.
Grahame Grieve (Jun 17 2016 at 13:09):
I'll think about language that captures the problem - in a robust fashion. The problem is that there's a number of implementations ,and expressing it one way doesn't work for them all
John Moehrke (Jun 17 2016 at 13:11):
and THAT is what worries me... you are trying to create a door for those that are refusing to live by any rules... thus you are creating a door for EVERYONE ELSE to live by no rules.
John Moehrke (Jun 17 2016 at 13:11):
which dilutes the brand to NULL.
Grahame Grieve (Jun 17 2016 at 13:13):
that's a false dichotomy. we are defining and governing a space for people to buy into some of the rules, and benefit from them, without buying into all of them. Extensibility
Grahame Grieve (Jun 17 2016 at 13:13):
it's not all or nothing - unless we make it all or nothing
John Moehrke (Jun 17 2016 at 13:13):
I suspect this is the case... so I try to figure out what is the compelling argument to allow this -unnamed- powerful group do something useful, so that the rest of us can understand and help craft the rules
Grahame Grieve (Jun 17 2016 at 13:15):
the use cases are in the wiki page. You don't find them compelling? why not?
Last updated: Apr 12 2022 at 19:14 UTC
