I am new in FHIR, I want to develop FHIR's Server in C#, Please help me how to handle Resource within Resource. For Example in Encounter Resource, (partOf : Resource(Encounter)), similarly in Organization resource there is Organization etc, I am trying but it goes to Infinite LOOP. Not proceed to next classes.I am retrieving data from Database for time being... Thanks in advance
When you look at the definition of a Resource and you see an element with a datatype of Resource(X) (like the example you mentioned, partOf: Resource(Encounter)) this means that resource references another Resource (in this case, an Encounter). The 'partOf' element is actually an URL (or rather, an uri) pointing to another resource somewhere else on the same RESTful endpoint (or within the same message or document if you are using those constructs). So, this is more like a 'foreign key' in "traditional" database technology.
So, yes, Organizations can reference Organizations, Encounters can reference Encounters!
In my tutorial on FHIR (available at http://www.slideshare.net/ewoutkramer/fhir-tutorial-morning), you can find some examples and background from slide 29 on. Basically, this is what a reference looks like:
<partOf>
<reference value='http://spark.furore.com/fhir/Organizaiton/4433EF-33'/>
<display value="Some other organization"/>
</partOf>
Note that this is very different from containment. If you take a look at the same Encounter resource (at http://www.hl7.org/implement/standards/fhir/encounter.html), you'll see a component 'Hospitalization', this component is nested within the resource (so no reference), as indicated by the "closed diamond" shape in the UML.
In case you need an example of how to implement a .NET FHIR server, please take a look at our open-source implementation here: http://www.github.com/furore-fhir/spark. Also, be sure to get the .NET helper API's via NuGet (just look for FHIR).
With regard to the infinite loop, it's entirely possible for references to loop back to an initiating resource. While resources don't generally point directly to themselves, traversing a chain of resources and winding back up at the starting resource is quite possible. Systems that traverse links will need to account for this potential looping.
Related
We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information. If I am creating a new index, should it not be POST instead of PUT? PUT does make sense when creating a document as it changes the state of data.
Your statement
As far as I know, POST is usually used for changing the state of the server, and PUT usually for updating the information.
does conform to the conventional HTTP vs CRUD semantics:
HTTP method
CRUD equivalent
Description
POST
Create
Let the target resource process the representation enclosed in the request.
PUT
Update
Set the target resource’s state to the state defined by the representation enclosed in the request.
However, the PUT spec also stipulates that:
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload
As such, PUT can (and is) used in Elasticsearch to both create an index AND update its
[settings and mappings].
Also, keep in mind that it's rarely just a matter of strict adherence to the semantics. One of the creators of ES put it this way:
It's all about REST semantics.
And our understanding of the semantics at the time when we made the APIs. And backwards compatibility constraints. And whatever "feels" natural to the person who implemented the API.
Where it makes a lot of sense Elasticsearch maps the HTTP verbs to
useful things. But when it doesn't make a ton of sense we just go with
whatever verb feels good rather than trying to be super strict about
REST. Also, we don't do linked data, instead relying on you to build
links from context. I'm told that is particularly non-REST. But it is
what we do.
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
Being relatively new to Chef, I am required to create libraries or definitions from existing recipes.
There recipes use bash resource, ruby block resource (which notifies another ruby block resource with delayed timing), template resource again which notifies a ruby block etc.
What would be the best approach to this? Library or definition?
I have read that if I use definition, I won't be able to notify a resource within the definition, does that mean I can notify a resource in a different definition file?
I also read that in libraries you cant use the resources directly. If this is true, how can I use a resource within my library?
So, this is "primarily opinion based", but I'll answer it anyway. There are 4 distinct choices here:
Definition
LWRP
HWRP
"Library"
A definition is just a wrapper around one or more resources with some parameterization. However, definitions are not added to the resource collection. Meaning you can't "notify" or trigger events on a definition. They are solely for wrapping and naming a series of repeatable steps found in a recipe.
An LWRP (Light-weight resource and provider) is a Chef-specific DSL that actually compiles into an HWRP (Heavy-weight resource and provider) at runtime. Both LWRPs and HWRPs are Chef extensions. In addition to wrapping a series of repeatable tasks, *WRPs will create a top-level resource in Chef (like template or package) that's available for use in your recipe and other cookbook's recipes as well.
The difference between and LWRP and HWRP is really the Ruby. HWRPs use full-blown Ruby classes. If you aren't a Ruby developer, they may be a bit intimidating. Nonetheless, you should give it a try before writing and LWRP. LWRPs use a Chef-specific DSL for creating resources. At the end of the day, they compile to (roughly) the same code as the Heavy-weight counterpart. I'll link some references at the end. You have access to Chef resources inside either implementation, as well as the run_context.
Finally, "libraries" (notice the quotes) are often misunderstood and abused. They are Ruby code, evaluated as Ruby, so they can do pretty much anything. HWRPs are actually a form of a library. Sometimes people use libraries as "helpers". They will create a helper module with methods like best_ip_for or aggregate_some_data and then "mix" (Rubyism) that library into their recipes or resources to DRY things up. Other times, libraries can be use to "hack" Chef itself. The partial-search cookbook is a good example of this. Facebook talked about how they limited the number of attributes sent back to the server last year at ChefConf too. Libraries are really an undefined territory because they are the keys to the kingdom.
So, while I haven't actually answered your question (because it's opinion-based), I hope I've given you enough information about the best direction moving forward. Keep in mind that every infrastructure is a special snowflake and there is no right answer; there's only a best answer. I'd suggest sharing this information with your team and weighing the pros and cons of each approach. You can also try the Chef mailing list, on which people will give you many opinions.
Resources:
LWRPs
HWRPs
Libraries
Modern Chef terminology has rebranded "LWRPs" as "Custom Resources" and the "Provider" that is the "P" of the "LWRP" has melted into the background and users just run actions now (the action_class is the way to access the old provider class).
Definitions still exist, are still discouraged, and still have known bugs which will never be fixed. There is no reason to use them.
Custom Resources are what everyone should use. More people should move recipe code into custom resources for reusability. The basic steps are simple:
Move the code into a resources file
Wrap the code with an action
Add a provides line for the name of the resource
Change the include_recipe call in recipes into a call to the custom resource.
That's all that is necessary for simple cases. Once that is done the resource can now be extended by adding properties, or existing node attributes can be converted into properties (the node attributes can be pushed back into the call to the resource from recipe mode).
For modern resources on Chef-15/16 consider setting unified_mode true to remove the compile/converge phase from the custom resource and simplify writing the resource.
For an example of the conversion of a simple recipe to a custom resource see this answer
My VB6 product may or may not have an embedded resource included in the executable.
What VB6 code would determine whether a certain embedded resource exists?
It depends on the kind of resource. VB6 has three different LoadRes<type> functions, and the proper one to use depends on the resource type. For instance, to load an image resource you use LoadResPicture. (There are links to the other functions in the tree menu on the left side of the linked page.)
Call the appropriate function, and if it returns the proper resource it's there. Handle the error if it's not, and you should be set.
This article may help.