Stream: IG creation
Topic: From IG to working server
Jose Costa Teixeira (Sep 01 2021 at 21:02):
There have been some discussions about DevOps'ing our work a bit further, namely by allowing the IG author to have a very simple way to roll out a server directly based on the IG Publication.
This would be similar to the awesome Yellow Button, but perhaps with some additional magic dust.
Grahame Grieve (Sep 01 2021 at 21:03):
HAPI has something similar
John Moehrke (Sep 01 2021 at 21:04):
what is wrong with the build.fhir.org/ig site?
Jose Costa Teixeira (Sep 01 2021 at 21:07):
Grahame Grieve said:
HAPI has something similar
Hapi has the foundation, the idea is to put it to use.
Grahame Grieve (Sep 01 2021 at 21:10):
I don't know how we would do that
John Moehrke (Sep 01 2021 at 21:11):
sounds like re-inventing simplifier
Jose Costa Teixeira (Sep 01 2021 at 21:11):
We can add something to the IG template like "Run the following docker command line and you'll get a server with this IG's content"
Jose Costa Teixeira (Sep 01 2021 at 21:12):
With that as a starting point, we can then look into more interesting stuff like
- setting up the IG's CapStatement
- putting swagger into it, if that's available
...
Jose Costa Teixeira (Sep 01 2021 at 21:12):
@Oliver Egger this could be the basic hapi or the matchbox, for example
Jose Costa Teixeira (Sep 01 2021 at 21:13):
and @Jens Villadsen will know more magic that can be done ther
Jens Villadsen (Sep 01 2021 at 21:14):
At your service. How may I assist you
Jose Costa Teixeira (Sep 01 2021 at 21:15):
John is not an enthusiast yet, but I think we can add some magic here.
John Moehrke (Sep 01 2021 at 21:15):
:-)
John Moehrke (Sep 01 2021 at 21:16):
I have full faith in Jose magic
Jens Villadsen (Sep 01 2021 at 21:17):
Are we talking about a one liner to roll out a FHIR server that automatically support a list of IG's that can validate ressources against the profiles from those IG's?
Jose Costa Teixeira (Sep 01 2021 at 21:18):
i can put a first experiment in a template somewhere
image.png
Jose Costa Teixeira (Sep 01 2021 at 21:18):
what I would like is some discussion to see what / how we can do
Jose Costa Teixeira (Sep 01 2021 at 21:18):
Jens Villadsen said:
Are we talking about a one liner to roll out a FHIR server that automatically support a list of IG's that can validate ressources against the profiles from those IG's?
Right
Jens Villadsen (Sep 01 2021 at 21:18):
Makes sense to me
Jens Villadsen (Sep 01 2021 at 21:19):
And a lot of my clients
Jose Costa Teixeira (Sep 01 2021 at 21:20):
Later we can look at adding more stuff there.
For example discussing how can we set the server's CapabilityStatement instead of using the "supported resources" thing in hapi config
Jose Costa Teixeira (Sep 01 2021 at 21:20):
I'd think that swagger would be awesome but I have no idea how that would work
Jens Villadsen (Sep 01 2021 at 21:20):
Swagger is autogenerated by HAPI
Jose Costa Teixeira (Sep 01 2021 at 21:21):
is swagger always published? even in plain vanilla hapi? i don't know how to see it
Jens Villadsen (Sep 01 2021 at 21:22):
http://hapi.fhir.org/baseR4/swagger-ui/
Jose Costa Teixeira (Sep 01 2021 at 21:25):
I think if I launch the basic hapi, that doesn't show up
Jens Villadsen (Sep 01 2021 at 21:26):
Make and issue on https://github.com/hapifhir/hapi-fhir-jpaserver-starter and Ill add it
Jens Villadsen (Sep 01 2021 at 21:29):
I hadnt heard about the yellow button before (i dont use simplifier) - but Ive been building one liner setups for my clients for at least a year know I think
Jens Villadsen (Sep 01 2021 at 21:32):
@John Moehrke there is nothing wrong with http://build.fhir.org/ig/ - it just isnt operational for testing actual setups. The intention here is to actually set up a FHIR server with the IGs wanted
Jose Costa Teixeira (Sep 01 2021 at 21:34):
Jens Villadsen said:
Make and issue on https://github.com/hapifhir/hapi-fhir-jpaserver-starter and Ill add it
https://github.com/hapifhir/hapi-fhir-jpaserver-starter/issues/270
Jose Costa Teixeira (Sep 01 2021 at 21:35):
(included a reference to ReDoc - in a first experiment, it looked a bit more awesome than swagger- ui :)
Jose Costa Teixeira (Sep 01 2021 at 21:56):
@Peter Robinson I just noticed your question - perhaps interesting to know that we could do that, and in an automated way.
Lloyd McKenzie (Sep 01 2021 at 23:07):
We need to be cautious here. If all the IG does is define expectations for specific REST functions, then you could theoretically generate a server for a particular CapabilityStatement. However, if the IG sets expectations for custom operations, messages or documents, or if it defines 'special' server-side mustSupport capabilities or SearchParameters with complex behavior, the "auto-server" won't do everything (or maybe anything) it would be expected to do.
Jose Costa Teixeira (Sep 01 2021 at 23:21):
Right. That's a good requirement, that somehow we could add a generic disclaimer (or better, a specific disclaimer like "note that the server won't support the following things:".
Jose Costa Teixeira (Sep 01 2021 at 23:23):
I think there's a bit of work to do before we are at that point. For now even the CapabilityStatement thing is not clear to me.
What do we do if an IG has 2 CapStatements? Or none? Is that possible and desireable to limit hapi's "supported_resource_types" to the resources mentioned in the IG? What about the IGs that this IG dependsOn?
Jose Costa Teixeira (Sep 01 2021 at 23:24):
(these are just some questions, I don't know how far we are with any of those, or even if they are pertinent)
Grahame Grieve (Sep 02 2021 at 00:12):
right. Systems support CapabilityStatements, not necessarily IGs. Presumably the firely thing only works in specific circumstances
Jens Villadsen (Sep 02 2021 at 08:22):
We won't be able to automate everything here - especially not custom operations and custom search parameters - but we can automate a lot of other stuff - and that part IMHO is worth trying to embrace
Jens Villadsen (Sep 02 2021 at 08:24):
so initially, I propose that big fat disclaimer saying that loading of custom search parameters, custom operations and capability statements won't be supported
Jose Costa Teixeira (Sep 02 2021 at 10:36):
Agree. We should perhaps have not only a link but an actual page that describes these limitations
Peter Robinson (Sep 02 2021 at 11:43):
from the above discussion I gather that I may have been asking the wrong question. But if it is not possible to adjust the behavior of a FHIR server with a custom IG than what is the point of a custom IG?
Jose Costa Teixeira (Sep 02 2021 at 11:44):
It is possible to adjust the behavior. This discussion is "How much of that can that be done by a machine?"
Jose Costa Teixeira (Sep 02 2021 at 11:53):
@Peter Robinson so you can for example (today) start a server which contains the IG resources. It does not limit the server, it just adds the resources
Jens Villadsen (Sep 02 2021 at 14:51):
And the validation against those resources
Lloyd McKenzie (Sep 02 2021 at 17:33):
In most cases, supporting an IG is going to involve a human looking at a spec and writing code.
Jose Costa Teixeira (Sep 02 2021 at 18:14):
sure, also because the ig will contain narrative
Jose Costa Teixeira (Sep 02 2021 at 18:15):
but if I want to support a simple content validator, that could be useful already for some testing, I think
Jose Costa Teixeira (Sep 02 2021 at 18:16):
I'm interested in creating some IG - one with questionnaires - that we can use. It could start with 2 profiles (so that we can see if the deployment and validation are working ok), and then we can think of more features.
Jose Costa Teixeira (Sep 02 2021 at 18:16):
the questionnaires will be for adding some more fancy stuff ahead
John Moehrke (Sep 02 2021 at 18:24):
I do think this is useful. Presume you suck in all the examples too? I do worry that some will assume that this lightweight system does more than it does.
John Moehrke (Sep 02 2021 at 18:26):
On an IHE call today we came up with some cases that would fit this nicely... Imagine an IG that intends to show a specific layout/configuration of a vhDIR. This is dominanted by things that would be replicated by this kind of lightweight system based on the IG.
John Moehrke (Sep 02 2021 at 18:28):
where the IG is vhDIR compliant, but further refines based on a regions needs. Might have profiles, vocabaulary, value sets.. but would certainly have examples....
Jose Costa Teixeira (Sep 02 2021 at 18:31):
John Moehrke said:
Presume you suck in all the examples too?
Yes, I presume that
I do worry that some will assume that this lightweight system does more than it does.
That is a worry I share. We can try to disclaim ourselves out of that worry
John Moehrke (Sep 02 2021 at 18:39):
yup
Peter Robinson (Sep 02 2021 at 21:58):
I see -- so it is not possible to start a HAPI server, upload a new IG, and have it validate FHIR code that conforms (or not as the case may be) with the IG? If instead one needs to write code, where would this code "live"?
Grahame Grieve (Sep 02 2021 at 22:08):
that's question for #hapi but the answer is yes to some degree
John Moehrke (Sep 09 2021 at 13:12):
Has there been progress on this? as I indicated, I have a need. specifically for a VM
Jose Costa Teixeira (Sep 09 2021 at 16:09):
I think we may have something next week
Jose Costa Teixeira (Sep 09 2021 at 16:11):
We can start with something very basic and progressively add integration between the IG and the server
Jose Costa Teixeira (Oct 01 2021 at 18:57):
After some experiments, it's possible to roll out the hapi server from the IG.
Jens Villadsen (Oct 01 2021 at 18:58):
Jose Costa Teixeira said:
John Moehrke said:
Presume you suck in all the examples too?
Yes, I presume that
I do worry that some will assume that this lightweight system does more than it does.
That is a worry I share. We can try to disclaim ourselves out of that worry
I don't share that worry at all
Jose Costa Teixeira (Oct 01 2021 at 18:58):
At this moment, this comes down to a docker command line like this:
docker run -p 8080:8080 -e hapi.fhir.default_encoding=json -e "--spring.config.location=https://hl7belgium.org/profiles/ehealth/be-core/application.yaml" hapiproject/hapi:latest
Jose Costa Teixeira (Oct 01 2021 at 19:00):
(the actual key work was done by @Jens Villadsen , I'm just stealing all the good ideas)
Jens Villadsen (Oct 01 2021 at 19:01):
(and I benefit from it by having you to explore features I didn't even recall having done)
Jose Costa Teixeira (Oct 01 2021 at 19:01):
(btw @John Moehrke we can more or less exhaustively tell people "this is not a miracle machine yet", but the focus now is on making it an actual miracle machine)
Jose Costa Teixeira (Oct 01 2021 at 19:02):
this requires a change to the template, and probably some more magic. So a few questions:
Jose Costa Teixeira (Oct 01 2021 at 19:08):
The ability to create a server requires a package or a url.
Jose Costa Teixeira (Oct 01 2021 at 19:09):
/poll What kind of packages / urls should be supported for rolling out a server?
Only Releases (i.e. refer to a registered package or canonical URL)
Releases and any published version (e.g. build.fhir.org/ig/my-ig)
Releases, published versions and anything else (e.g. file:///c:/users/....)
Jose Costa Teixeira (Oct 01 2021 at 19:10):
(of course, the above sequence is increasing in complexity)
Jose Costa Teixeira (Oct 01 2021 at 19:12):
Another question: When we roll out a server with one IG, what resources should the IG support?
Jose Costa Teixeira (Oct 01 2021 at 19:16):
/poll What resources to support on a server
Only those in the IG
Depends on a parameter "supported_resources" which takes a list such as ["all"] or ["resource1", "resource2",... ]
Depends on a CapabilityStatement in the IG - if there is a CapStatement, we use the CapStatement for the list of exposed resources. If not, we expose all. (TBD - what if the IG has several CapStatements)
Jens Villadsen (Oct 01 2021 at 19:17):
Jose Costa Teixeira said:
/poll What kind of packages / urls should be supported for rolling out a server?
My answer would be any kind of package/url - be that local on disk or any other placee. Ain't the goal to be able to roll out test servers as early as possible in order to collect feedback?
Jose Costa Teixeira (Oct 01 2021 at 19:18):
Yes, that is the hardest but most devops'y
Jens Villadsen (Oct 01 2021 at 19:18):
how is that any harder?
John Moehrke (Oct 01 2021 at 19:21):
The questions you are asking are so beyond my SME. so, I can't answer them. Sorry, I am too stupid. I just want a way to deploy a test server given an IG. Beyond that seems like advanced work. The examples need to be in the IG... now once a server is running, it will RESTfully take on others.
Jens Villadsen (Oct 01 2021 at 19:23):
@John Moehrke SME?
John Moehrke (Oct 01 2021 at 19:25):
subject matter expertise. --- I am not smart enough to answer the questions.
Jose Costa Teixeira (Oct 01 2021 at 19:27):
@John Moehrke you raised the issue that people may think too much of the server. What I'm suggesting (for now) is : that's life. So that we don't lose traction looking into that.
Jens Villadsen (Oct 01 2021 at 19:30):
(thought SME was Subject matter expert - and then the sentence didn't made sense to me... but ok - I learned something there ;) )
Jose Costa Teixeira (Oct 01 2021 at 19:30):
Jens Villadsen said:
how is that any harder?
The way I think this should be implemented requires the yaml file or command line to take that location. And I would want that command line to be not in the head of the user but explicit in the IG. And to put this in the IG, there is some increasingly powerful magic needed.
Jens Villadsen (Oct 01 2021 at 19:31):
if the example command line is rendered on the html page, can't you just figure out the location using javascript?
Jens Villadsen (Oct 01 2021 at 19:32):
I mean - you intend to state the example terminal command on the IG pages right?
Jens Villadsen (Oct 01 2021 at 19:34):
window.location.href would get you the location, right?
Jens Villadsen (Oct 01 2021 at 19:36):
and that can be used regardless of it being rendered locally, on build.fhir.org or anywhere else
Grahame Grieve (Oct 01 2021 at 19:52):
Releases and any published version
Assuming any published branch
Jens Villadsen (Oct 01 2021 at 19:54):
why not local work?
Grahame Grieve (Oct 01 2021 at 20:14):
complexity. for me
Jens Villadsen (Oct 01 2021 at 20:16):
how's 'localhost' more work?
Jose Costa Teixeira (Oct 01 2021 at 20:16):
Jens Villadsen said:
if the example command line is rendered on the html page, can't you just figure out the location using javascript?
I can and that is what I have just now. The difficulty is that currently that is all in the application.yaml which I have to build before the javascript
Jose Costa Teixeira (Oct 01 2021 at 20:17):
I can use your idea of overriding the yaml properties. that would mean some logic but seems doable
Jens Villadsen (Oct 01 2021 at 20:20):
as I expected - I suggest you override it - at least for now
Jose Costa Teixeira (Oct 01 2021 at 20:21):
so perhaps we could do this:
a) the yaml uses the url of the IG. that is the default command line
b) if the javascript detects that the current URL is different from the URL of the IG (i.e. if the location.href is not the same as the ig url), present that as a command line (instead of? in addition to? the default command line)
Jose Costa Teixeira (Oct 01 2021 at 20:21):
And actually this would work for any location - branches, canonicals, etc.
Jose Costa Teixeira (Oct 01 2021 at 20:21):
would that be satisfactory?
Jose Costa Teixeira (Oct 01 2021 at 20:26):
if so, i guess i just need some guinea pig template to try this on. Good thing we can now test IG template branches :)
Jose Costa Teixeira (Oct 01 2021 at 21:16):
Any ide of if/how I can read a property from a yaml file using JS (in the browser)?
Jens Villadsen (Oct 02 2021 at 14:04):
https://stackoverflow.com/a/8065087
Jose Costa Teixeira (Oct 03 2021 at 09:02):
Is this a good solution for now?
image.png
Jose Costa Teixeira (Oct 03 2021 at 09:03):
i.e. 2 lines. The first one is the ig's url, the other one is whatever-you-are-looking-at-right-now
Lloyd McKenzie (Oct 03 2021 at 14:41):
I think we should qualify "your own running server" to indicate that some functions, such as complex custom search parameters, messaging, operations and document behaviors may not be implemented or may only be partially implemented.
Jose Costa Teixeira (Oct 03 2021 at 17:06):
Right. I believe that is the same concern as @John Moehrke 's . We should disclaim that by adding narrative. We can work on this when bringing this to the template - I can create a branch template for anyone to test and improve..
Jose Costa Teixeira (Oct 03 2021 at 17:08):
OTOH, I do hope that such a concern actually drives us to work on implementing those extra capabilities.
I bet @Jens Villadsen will see this motivation as the positive side of such pain.
Jens Villadsen (Oct 03 2021 at 17:11):
Pain is just a feeling leaving the body :sunglasses:
Jens Villadsen (Oct 03 2021 at 17:12):
At least that is what my old sergeant said
Jens Villadsen (Oct 03 2021 at 17:15):
We could add an error response for all the stuff we definetly cant handle
Jens Villadsen (Oct 03 2021 at 17:16):
Probably needs to be configurable
Jens Villadsen (Oct 03 2021 at 17:17):
Who wants to bring an example IG?
Jose Costa Teixeira (Oct 04 2021 at 11:23):
Jens Villadsen said:
Probably needs to be configurable
Configurable how? Or do you mean the whole thing should be a toggleable feature?
Jose Costa Teixeira (Oct 04 2021 at 11:24):
Jens Villadsen said:
Who wants to bring an example IG?
The IG I used initially is not the authentic source. At this moment I have others but nothing that is ready yet
Jose Costa Teixeira (Oct 04 2021 at 11:25):
I think a good IG would be onle like the core-BE - only CapStatements and terminology resources, not a lot of (relevant) narrative.
There is a dk-core, right?
Jose Costa Teixeira (Oct 04 2021 at 11:26):
Switzerland may have a good set of IGs to add this feature to - @Roeland Luykx @Oliver Egger ?
Oliver Egger (Oct 04 2021 at 14:34):
How about the IHE MHD implementation guide? https://profiles.ihe.net/ITI/MHD/artifacts.html There are a lot of different kind of resources in there.
Jose Costa Teixeira (Oct 04 2021 at 15:18):
Could be. But MHD does seem to have quite some stuff that is defined in narrative, right?
Jose Costa Teixeira (Oct 04 2021 at 15:20):
And if that's the case, then we may need to disclaim a lot as @John Moehrke was mentioning. Or we don't, and we just let people enjoy the suffering.
Oliver Egger (Oct 04 2021 at 15:23):
there are a lot of conformance resources behind also with examples in MHD
Jose Costa Teixeira (Oct 04 2021 at 15:45):
OK. Meanwhile I'll get a questionnaire-based IG ready.
But we can add this to MHD indeed.
Jens Villadsen (Oct 07 2021 at 17:32):
can we agree on that it would be a bit weird to start with the IHE MHD client facing IG's
Jose Costa Teixeira (Oct 07 2021 at 17:58):
My preference is to have something that people can actually demo on a more functional side. Hence my thought of the Questionnaire.
I'm working on this for a drug catalog, but I can also add a vaccination-related IG.
I can't say if MHD would be useful - perhaps so, but more for architects(?).
Jose Costa Teixeira (Oct 07 2021 at 17:59):
In any case, what we'll have is a template update - so technically any IG would work
Oliver Egger (Oct 07 2021 at 21:29):
if you prefer questionnaires the swiss rad order ig has questionnaires, structure map and profiles ...
Jens Villadsen (Oct 10 2021 at 12:13):
okay - so what do we need to change / build?
Jose Costa Teixeira (Oct 10 2021 at 15:26):
I'll post a dev branch for our common template which I think is the base template...
Jose Costa Teixeira (Oct 15 2021 at 13:54):
/poll I'm wondering if this FHIR server-on-a-click is a useful thing
Yay
What?
Nope
Jens Villadsen (Oct 16 2021 at 21:54):
Try to take new-comers dev view to it. If you hardly know what an IG is this, and you would like to start fiddling with a test server that you've been told will host if not all then most of the rules, then this is an execellent way of getting your hands on it
Jens Villadsen (Oct 16 2021 at 21:55):
I've used this multiple times for clients and while they may not be experts on FHIR, I've made them they understand what this sort of mechanism accomplishes.
Grahame Grieve (Oct 16 2021 at 21:56):
what does it accomplish?
Jens Villadsen (Oct 16 2021 at 21:56):
a test server
Jens Villadsen (Oct 16 2021 at 21:57):
that can be used locally
Jens Villadsen (Oct 16 2021 at 21:57):
as well as globally
Jens Villadsen (Oct 16 2021 at 21:57):
enforcing profiles
Jens Villadsen (Oct 16 2021 at 21:58):
and exposing a bit more than just the rudimentary
Jens Villadsen (Oct 16 2021 at 21:59):
so instead of just giving them a hammer, why not provide an entire toolbox when we can do so.
Jens Villadsen (Oct 16 2021 at 22:00):
it is an excellent way of getting quickly up and running - and I've seen it multiple times
Jens Villadsen (Oct 16 2021 at 22:03):
Is it because our clients and their needs are very different since we seem to be 50% for and 50% not-so-much?
Grahame Grieve (Oct 16 2021 at 22:25):
I, at least, think that's deceptive. Sure, you can preload a general purpose server with the profiles and value sets etc from an implementation guide, and it can enforce what it can, but it's still not the same thing as an actual conformant server in some really important regards
Jens Villadsen (Oct 16 2021 at 22:26):
noone said so
Jens Villadsen (Oct 16 2021 at 22:27):
but what would you prefer for testing: nothing - or something close to reality?
Jens Villadsen (Oct 16 2021 at 22:27):
we are not aiming for 100% here - we're aiming for making it easier
Jens Villadsen (Oct 16 2021 at 22:28):
we are aiming for providing value more quickly
Lloyd McKenzie (Oct 16 2021 at 22:33):
Is the server actually going to enforce the profiles? I.e. will it yell if inbound data doesn't comply? Will it enforce that outbound data does comply? (We can't assume that instances will actually declare the profiles, as that's not something we want to encourage.)
Jens Villadsen (Oct 16 2021 at 22:38):
that behaviour is configurable for the inbound part - I suggest to default for enforcing it - because that is what newcomer's will expect.
Grahame Grieve (Oct 16 2021 at 22:42):
enforcing what?
Jens Villadsen (Oct 16 2021 at 22:48):
@Lloyd McKenzie - right, the current behaviour requires that the profile is declared, and that part is not optimal. That is currently the trade-off
Jens Villadsen (Oct 16 2021 at 22:49):
@Grahame Grieve enforcing the validation of the inbound resource to the declared profile
Grahame Grieve (Oct 16 2021 at 22:49):
what declared profile?
Jens Villadsen (Oct 16 2021 at 22:50):
whatever profile the client stated in the meta
Jens Villadsen (Oct 16 2021 at 22:50):
if known to the server
Jens Villadsen (Oct 16 2021 at 22:50):
The documentation of the feature is here: https://hapifhir.io/hapi-fhir/docs/validation/repository_validating_interceptor.html
Jens Villadsen (Oct 16 2021 at 22:50):
the stock example implementation is here: https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/master/src/main/java/ca/uhn/fhir/jpa/starter/RepositoryValidationInterceptorFactoryR4.java
Lloyd McKenzie (Oct 16 2021 at 22:55):
If it requires declaring the profile in the instance, then I don't think we should be providing this - because it causes people to think they need to do something that they don't (and generally shouldn't).
Grahame Grieve (Oct 16 2021 at 23:05):
and anyway, all you have to do is turn validation on on a normal server to get that
Jens Villadsen (Oct 16 2021 at 23:11):
whats a 'normal server'?
Jens Villadsen (Oct 16 2021 at 23:13):
it should be doable to construct a piece of logic that does not require the inbound metadata to be present - but it aint there yet
Jens Villadsen (Oct 16 2021 at 23:13):
would that change your oppinion on this matter?
Grahame Grieve (Oct 16 2021 at 23:19):
maybe. I have proposed that before, but it didn't go anywhere. but it's still not the same thing. That's why I haven't been highly motivated by this.
Jose Costa Teixeira (Oct 17 2021 at 08:01):
Lloyd McKenzie said:
Is the server actually going to enforce the profiles? I.e. will it yell if inbound data doesn't comply? Will it enforce that outbound data does comply?
I would like that to be on the plan, yes. So whenever I POST a Patient, if the server only accepts MyPatient profiles, I wouldn't have to declare the meta.
Jose Costa Teixeira (Oct 17 2021 at 08:01):
@Jens Villadsen Isn't that what the supportedresourcetypes should do?
Jose Costa Teixeira (Oct 17 2021 at 08:23):
(and/or based on CapabilityStatement.rest.resource.profile)?
Jens Villadsen (Oct 18 2021 at 07:43):
@Jose Costa Teixeira yes and no. supported_resource_types limits the set of supported resources types on the server. If you eg. only state patientand observation, the server will never accept any other resources - regardless of what IG's have been loaded. It is a crude way to limit what the server can do - regardless of .meta and loaded IG's. What we/I can build is a verfication that will validate each incoming resource against all profiles among the loaded IG's (we already have the feature to load the IG's) that matches the type, and then accepts the resource if there's just a single match. As I understand both @Grahame Grieve and @Lloyd McKenzie this is what should happen. While that may work in theory I would like to hear from those to guys how that is supposed to scale in reality, when many IG's are loaded and part of a server.
Jens Villadsen (Oct 18 2021 at 07:46):
So @Jose Costa Teixeira thinking about it - we may or may not need the CapabilityStatement.rest.resource.profile as we might just as well look at all the profiles stored on the server
Jens Villadsen (Oct 18 2021 at 07:47):
But ofc - it can be used as a filter to limit the set of profiles
Jose Costa Teixeira (Nov 01 2021 at 18:40):
This is now implemented in my template branch.
What would the "proper" implementation do?
Jose Costa Teixeira (Nov 01 2021 at 18:41):
Loading the packages is simple. Other things I can think of:
- Add SearchParameters?
- Set the CapabilityStatement / allowed profiles?
- ...
Jose Costa Teixeira (Nov 01 2021 at 18:41):
and Q2: do we want to discuss this in a call e.g. tomorrow?
Lloyd McKenzie (Nov 01 2021 at 21:16):
We have a bit more feedback on process, but we can certainly talk about this time-allowing
Jose Costa Teixeira (Nov 02 2021 at 14:57):
We can also do it next week to make it more worthwhile for people from Europe. @Jens Villadsen preference?
Jens Villadsen (Nov 02 2021 at 14:58):
Im ready whenever
Jens Villadsen (Nov 02 2021 at 14:59):
But i need an invite
Jens Villadsen (Nov 02 2021 at 17:23):
@Jose Costa Teixeira wheres the meeting info
Jose Costa Teixeira (Nov 02 2021 at 17:52):
http://www.hl7.org/concalls/CallDetails.cfm?concall=56649
Jens Villadsen (Nov 02 2021 at 19:55):
there's something seriously defunct about exported ics file
Jens Villadsen (Nov 02 2021 at 19:58):
@Jose Costa Teixeira so tonight in about an hour?
John Moehrke (Nov 02 2021 at 20:03):
yes, one more hour away
Jens Villadsen (Nov 02 2021 at 20:08):
its a shitty time, but if this is on the agenda I'll join. Will it be on the agenda?
Jens Villadsen (Nov 02 2021 at 20:52):
@Jose Costa Teixeira / @John Moehrke - is :point_up: on the agenda?
John Moehrke (Nov 02 2021 at 20:52):
@Lloyd McKenzie ?
Jose Costa Teixeira (Nov 02 2021 at 20:53):
that was my question. @Lloyd McKenzie replied "time allowing".
I would prefer to have a "next week for sure" than a "maybe today"
Jens Villadsen (Nov 02 2021 at 20:54):
I need a bit more commitment than that when attending this late
Jose Costa Teixeira (Nov 02 2021 at 20:57):
right, that was my goal. I'd suggest we skip this for today.
And given the obscenity of the call hour, we can perhaps this week take some minutes to plan next week's call?
John Moehrke (Nov 02 2021 at 21:03):
could we schedule a specific call for this?
Jens Villadsen (Nov 02 2021 at 21:05):
@John Moehrke you could discuss that on the call now
Jens Villadsen (Nov 02 2021 at 21:07):
and I would also still like to hear something on:
As I understand both @Grahame Grieve and @Lloyd McKenzie this is what should happen. While that may work in theory I would like to hear from those two guys how that is supposed to scale in reality, when many IG's are loaded and part of a server.
Last updated: Apr 12 2022 at 19:14 UTC
