I have registered this extension under an Imaging Study Resource and added a Custom Search Parameter for it.
"extension": [{
"url": "http://example.org/fhir/StructureDefinition/middlename-extension",
"extension": [{
"url": "middlename",
"valueString": "Rocky"
}
]
}
]
I want to now search for the valueString "Rocky" across the server and return any Imaging Study which has this extension value.
How can I define the Description and Xpath while registering the search parameter for this usecase?
I tried this but this would not work, am i missing something?
"expression" : "ImagingStudy.extension.where(url='http://example.org/fhir/StructureDefinition/middlename-extension').extension(url='middlename').value.as(String)",
"xpath" : "f:ImagingStudy/f:extension/f:extension/f:value/f:as[#valueString]"
The expression should either be
"ImagingStudy.extension.where(url='http://example.org/fhir/StructureDefinition/middlename-extension').extension.where(url='middlename').value.as(String)"
or
"ImagingStudy.extension('http://example.org/fhir/StructureDefinition/middlename-extension').extension('middlename').value.as(String)"
The xPath isn't used by any servers that I'm aware of, but for the record, it should be:
"f:ImagingStudy/f:extension[#url='http://example.org/fhir/StructureDefinition/middlename-extension']/f:extension[#url='middlename']/f:valueString/#value"
As a side note, you shouldn't be using a custom extension for the middle name. Middle names are conveyed as any repetition of HumanName.given other than the first. If you want to send a middle name without a first name, you could put a dataAbsentReason extension on the first 'given' repetition.
Related
I'm an absolute FHIR newbie and I'm trying to create a set of StructureDefinitions and examples for an upcoming medical project.
For this project, we need a very specific resource, which is not supported by any FHIR resource yet. Here's our use case:
We are placing sensors on our Patients while they execute certain exercises (e.g. a leg squat) - we capture the sensor measurements and based on those we assign a pre-calculated bio-mechanical body model to each individual Patient. Those body models are calculated and assigned somewhere else in our system (this process is not relevant here). In a first step, I would like to add all the pre-calculated body models itself to our FHIR dataset as resources - so that I'm able to output all existing body models in our system.
Such a body model consists of an unique identifier, a human readable title and a set of attributes which describe the body model. The crucial part are the attributes - those might vary for each body model and we don't know the set of possible attributes beforehand, hence I need a dynamic format representing key and value of each attribute. If I were to represent this in a simple json structure I'd look as follows:
{
"id": "0",
"title": "SAMPLE_BODY_MODEL",
"attributes": [
{
"key": "ATTRIBUTE_1",
"value": "EXAMPLE_1"
},
{
"key": "ATTRIBUTE_2",
"value": "EXAMPLE_2"
}
]
}
My goal now is to create a StructureDefinition corresponding to the custom resource I've described above.
Hence I looked up the topic of "custom resources" and found this article on the HL7 site: https://hl7.org/fhir/basic.html - explaining that the Basic resource should be used for custom resources.
So I went ahead and tried to create a basic resource and extending it:
{
"resourceType": "StructureDefinition",
...
"type": "Basic",
"differential": {
"element": [
{
"id" : "Basic",
"path": "Basic",
"definition": "This element describes a general body model captured during an exercise or a movement, e.g. whilst doing leg squats."
},
{
"id" : "Basic.id",
"path": "Basic.id",
"definition": "ID of the body model"
}
{
"id": "Basic.extension:title",
"path": "Basic.extension",
"sliceName": "definition",
"definition": "Title of the body model",
"min": 0,
"max": "1",
"type": [
{
"code": "string" // I know that's wrong, but I somehow would like to restrict this to a string only
}
]
},
{
"id": "Basic.extension:attributes",
"path": "Basic.extension",
"sliceName": "attributes",
"definition": "Attributes of the body model",
// This is where I'm stuck - how do I define this to be a list of objects consisting of attributes key and value?
}
]
}
}
To sum it all up: How do I create a new StructureDefinition from a basic resource allowing me to specify a new required attribute named "attributes", which consists of one-to-many elements, which again contain the attributes key and value for the key and value of the body model attributes?
Hope this makes sense - otherwise please feel free to let me know and I'll try to rephrase my question.
Many thanks in advance!
First, for a newbie, you're doing really well :) (And nice job on framing the question well too!)
Your first extension slice has a few issues:
sliceName should be "title", not "definition" - essentially the 'extra' bit in the id is the slicename
The 'type' needs to be Extension. (The type of all extensions is always Extension.) However, you should also specify a specific profile on Extension that indicates the canonical URL the StructureDefinition you've used to define the 'title' extension. That extension will have a context of Basic and will constrain extension.value[x] to be of type string and will also establish a fixed URL for extension.url.
Your second slice will be similar. However, the profile on extension it points to won't constrain extension.value. Instead, it'll slice extension.extension to have two slices, one with a fixed url of "name" and the other with a fixed url of "value". There's an example here of a 2-element complex extension. Your slice names and data types will differ, as will the context, but it should make a good model for you.
If you still have issues, add your revised version to your question and we'll see if we can help further.
I use multi-fields in a lot of my mappings. In the doc of Elastic Search there is an indication that multi-fields should be replaced with the "fields" parameter. See http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/_multi_fields.html#_multi_fields
This works fine. However, to access a multi-field as a single field the documentation recommends to specify the copy_to parameter instead of the path parameter (see http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-core-types.html#_accessing_fields)
Can somebody provide an example of such a mapping definition (thus using the "fields" parameter combined with "copy_to").
I have the impression that if you use the fields parameter you still need to specify the path parameter. And if you use copy_to, you no longer need to use a multi-fields approach; the fields just become separate fields and data of one field is copied to another at index time.
Hope somebody can help.
thx
Marc
I think that the copy_to option can be viewed as a cleaner variant of the Multi-fields feature (that is, the fields option). Both of these are easy to use when you want to "copy" values of a field to one or more other fields (to apply different mapping rules). However, if you need to "copy" values from multiple fields to the same field (that is, when you want a custom _all field), you must add the path option to the mapping, if you're using Multi-fields. On the other hand, with the copy_to option, you can simply point multiple source fields to the same destination field.
See this: https://www.elastic.co/guide/en/elasticsearch/reference/1.6/_multi_fields.html
copy_to would allow you to merge different fields like first_name and last_name into full_name
while multi field is used when you want to define several ways to index your field. For example
// Document mapping
{
"properties": {
"name": {
"fields": {
"name_metaphone": {
"type": "string",
"analyzer": "mf_analyzer"
},
"name_exact": {
"index": "not_analyzed",
"type": "string"
}
},
"type": "multi_field"
}
}
}
Is there a rule to define a sequential list of links using HATEOAS?
It is easy to add self, next and previous links to a HATEOAS-based response. Below is a sample response:
{
links : [{
rel : "next",
href : "http://localhost:8080/persons?page=1&size=20"
}],
content : [{
id: "",
name: "",
lastname: "",
age: 0
}],
pageMetadata : {
size : 20,
totalElements : 30,
totalPages : 2,
number : 0
}
};
So, pagination with next and previous links is not difficult but I couldn't figure out how it is possible to access for example 10th page directly, for example using a select element (let's assume there are more than 10 pages). Should I add all the links to the response as, for example, page1, page2, page3, etc? Of course I know the format of the request so I could just create the appropriate query but that seems kind of wrong because the whole point seems to be not relying on the actual link of the service. I am not an expert on this issue and I couldn't find an answer in this site or from Google.
Thanks in advance.
The common solution is to use URI templates. Specifically, section 3.2.8 regarding Form-Style Query Expansion.
Assuming both page and size are optional, you would construct your link URI template as localhost:8080/persons{?page,size}.
URI templates do not define which values are acceptable; there's no mechanism for restricting page or size to numeric values. As such, you should include this template in addition to your existing next/prev links. I'm not exactly sure which link relation best describes such a resource, but "collection" doesn't seem too far off.
In order to use URI templates, you'll need a library in whichever languages will be producing/consuming the template. A quick search produced a list of libraries in various languages which you may find helpful.
Lastly, depending on your hypermedia format you may need to specify a templated URI as such. For example, HAL+JSON uses a boolean templated property.
{
"_links": {
"collection": {
"href": "/persons{?page,size}",
"templated": true
}
}
}
From this question I can see that it is possible Use existing field as id in elasticsearch
My question is, if can do similar thing but concatenating fields.
{
"RecordID": "a06b0000004SWbdAAG",
"SystemModstamp": "01/31/2013T07:46:02.000Z",
"body": "Test Body"
}
And then do something like
{
"your_mapping" : {
"_id" : {
"path" : "RecordID" + "body"
}
}
}
So the id is automatically formed from concatenating those fields.
No you can't, you can only make the _id point to a field that's within the document, using the dot notation as well if needed (e.g. level1,level2.id).
I'd suggest to have a field that contains the whole id in your documents, or even better to take the id out and provide it in the url, as configuring a path causes the document to be parsed when not needed.
I've been taking baby steps into using Elasticsearch, and while researching a separate issue I ran into this question. Here, swatkins asked about querying nested objects, and a responder pointed out that nested objects weren't necessary given his model. I've copied the model here, and made some changes to reflect my particular question:
[{
id:4635,
description:"This is a test description",
author:"John",
author_id:51421,
meta: {
title:"This is a test title for a video",
description:"This is my video description",
url:"/url_of_video"
awesomeness-level: "pretty-awesome"
kung-fu: true
}
},
{
id:4636,
description:"This is a test description 2",
author:"John",
author_id:51421,
meta: {
title:"This is an example title for a video",
description:"This is my video description2",
url:"/url_of_video2"
kung-fu:false
monsters:true
monsters-present: "Dracula, The Mummy"
}
}]
Our application allows users to define custom metadata, so we're using a nested object to represent that data. At first glance, it looks similar to swatkins' model, so I thought that maybe we shouldn't be using a nested object.
The big difference is each objects meta might be different, note the second video has meta specifically about "monster movies", while the first video references an "awesomeness-level". So, should I be using a nested object, or just mapping metadata as a normal field? If we do the latter, will the first video have empty metadata fields? Does that really even matter? Thanks in advance!
Assuming that your example represents two elasticsearch documents, it doesn't look like you need to make meta a nested object. It makes sense to use nested objects when one parent object has multiple nested objects and your searches involve several fields of the nested objects. For example, if you have a record like this:
{
"name": "apple",
"attributes": [
{
"color": "yellow",
"size": "big"
},
{
"color": "red",
"size": "small"
}
]
}
and you want this record to be found when you search for color:yellow AND shape:big or color:red AND shape:small but don't want it to be returned when you search for color:yellow AND shape:small, it makes sense to make attributes a nested object. It will allow you to index and search each attribute independently and then get parent object of matching attribute.