Stream: conformance
Topic: Conformance as a list of features
Ewout Kramer (May 11 2016 at 16:01):
So, when I think about splitting Conformance up into a list of features, this is the kind of issues I think we should look at:
- Instead of a fixed list of features (like we have now), we will need a valueset of pre-coordinated codes that identify a feature
- If a feature is not a simple key/value pair, what do we do? How to handle features that have multiple aspects? Sub-features?
Grahame Grieve (May 11 2016 at 16:01):
I think you need to explain this better
Grahame Grieve (May 11 2016 at 16:02):
I have no idea what you mean
Ewout Kramer (May 11 2016 at 16:02):
Apart from this, I like the recent suggestion of defining an operation that the client could execute to ask the server: "do you support this?", which means that features should be a declarative statment of capabilities, but can also be used in the context of a client asking support for a feature.
Ewout Kramer (May 11 2016 at 16:04):
? I don't think it's that complex what I am saying? Isn't a conformance statement basically a list of <feature-code, support for feature> pairs?
Grahame Grieve (May 11 2016 at 16:17):
I think it's a little more than that. It's a structure 6 levels deep...
Ewout Kramer (May 11 2016 at 16:20):
Yes, so one of my bullets was: "if a feature is not a simple key/value pair..."
Ewout Kramer (May 11 2016 at 16:21):
I'll look at Conformance and give it a shot to see what it could look like.
Grahame Grieve (May 11 2016 at 16:22):
note that you could simplify the model and that would increase the size of the instance
Ewout Kramer (May 11 2016 at 16:24):
unless we'd introduce a Feature resource maybe (I think that was suggested previously)
Ewout Kramer (May 11 2016 at 16:24):
But then requesting ALL features would result in a Bundle that's certainly bigger than the current Conformance statement
Ewout Kramer (May 11 2016 at 16:25):
Hence the operation
Grahame Grieve (May 11 2016 at 17:18):
okay, then, I'll take this seriously. When I connect to a server, there's 3 different questions I want to ask:
- what version is it running?
- what resources does it support?
- for the intersection of the resources I'm interested in and it supports, what operations and search parameters are supported?
Grahame Grieve (May 11 2016 at 17:19):
that suggests that we could split Conformance on resource, and have a ResourceFunction thing for each resource + search parmaters
Grahame Grieve (May 11 2016 at 17:20):
and then 2 operations on conformance: $do-you-dot-this, and $conformance-for?resources=name,name,name....
Ewout Kramer (May 11 2016 at 17:39):
Well, I don't think that fixes that problem that there are ever more things people like to express... as Chris said:
Finally, it would allow definition of custom features (URI identified) without need for conformance extensions.
Of course, there's a tension here that we might well have a list of features that no client understands or know to ask for.
Grahame Grieve (May 11 2016 at 17:45):
and they sound like extensions
Grahame Grieve (May 11 2016 at 17:45):
I think it helps with the problem by breaking up the resource, and also allowing you to say which resources you are interested in
Chris Grenz (May 11 2016 at 17:52):
@Grahame Grieve I think the list of questions asked also includes some less obvious configuration distinctions (external URLs, @profile slicing) and ALL of this should be queried not just in the general context (pre-authentication) but also in a specific security context (post-authentication).
Chris Grenz (May 11 2016 at 18:09):
Might be a bit late for this...but I'd envision a flat list of features:
patient-read (http://hl7.org/fhir/FeatureDefinition/patient-read)
patient-vread (http://hl7.org/fhir/FeatureDefinition/patient-vread)
patient-update (http://hl7.org/fhir/FeatureDefinition/patient-update)
message-event-patient-link (http://hl7.org/fhir/FeatureDefinition/message-event-patient-link)
...
maybe grouped with a category or something.
Conformance then just become a list of features supported with the query operation to check for a subset. Query could be pre or post authentication (general server features, features in my context).
Chris Grenz (May 11 2016 at 18:10):
I'd then roll OperationDefintion, the potential MessageEventDefintion, and other feature defs into a FeatureDefinition resource with a canonical URL. Describe the feature here and link to TestScripts that technically define the feature.
Chris Grenz (May 11 2016 at 18:11):
An implemented that wanted to publish a feature then would have a consistent way of doing so and a server would have a consistent way to tell clients if that new feature is supported.
Chris Grenz (May 11 2016 at 18:13):
Doesn't make the Conformance smaller...but makes querying it for a set of features simple XPath (//feature[url/@value='http://.../patient-read']/supported or something)
Chris Grenz (May 11 2016 at 18:15):
Would also give a nice scope for security
John Moehrke (May 11 2016 at 18:31):
Chris I you are conflating concepts. The security model i a different thing than the object/Resource model. They are related, but different. What you have described seems very close to the OAuth 'scopes' that are being developed in projects like HEART and SMART. These projects 'have' a security model, so can lockdown this kind of thing. Where as the core FHIR specification can be used in many security models. It is only when you have a deployment project that you have enough Privacy and Security policy defined.
Chris Grenz (May 11 2016 at 18:58):
Hi John - I hope that's not what I'm doing...that's not my intent. I'm trying to define features/operations we've defined in FHIR in a abstract and consistent way so that implementations have something to hold on to when they (independently) define security models.
Chris Grenz (May 11 2016 at 18:58):
I'm not prescribing *how* the security implementations refer to these things, I'm just giving them a *what* to refer to consistently (I think).
Chris Grenz (May 11 2016 at 19:01):
I guess I don't think it's significantly "conflating" to say that a client should be able to ask for a list of features after authentication as long as we don't say anything about how they authenticate, how they are authorized, etc. They just are asking "now that I'm within my particular context, what things can I still do?"
John Moehrke (May 11 2016 at 19:03):
then I might have misunderstood... sorry
Chris Grenz (May 11 2016 at 19:04):
No worries - it's a fair and important question. We don't want to dictate security models, but we also need to foster some kind of consistency for interoperability to work.
Chris Grenz (May 12 2016 at 18:27):
Another thought on this - with a feature list you could add this into an IG and fully define compliance for a purpose (if I understand IGs correctly).
Josh Mandel (May 12 2016 at 18:29):
I think this is an idea that deserves consideration (maybe some prototyping).
Grahame Grieve (May 12 2016 at 18:32):
its' still not clear to me what this idea actually looks like
Josh Mandel (May 12 2016 at 18:32):
Me too! Just saying I'm intrigued.
Chris Grenz (May 12 2016 at 18:35):
I'll try and put a straw-man together...
John Moehrke (May 13 2016 at 11:08):
At the last WGM I proposed an IG that brought together the Document Sharing resources (ala MHD), and added to this patient directory, provider directory, consent management, audit logging. Most importantly it was going to define a deployment environment with a specific set of Policies (Privacy Policy, Security Policy, data retention policy, service level policy, etc). The result would have been a deployment IG, that could have driven connectathon tests beyond core FHIR Resouce interop... but it got shot down because HSI can't own anything. I ran out of energy to fight the system...
Last updated: Apr 12 2022 at 19:14 UTC
