In the last post we had a look at the page where we can create a new resource instance from a resource definition. We got to the point where we were about to enter data, so let’s pick up the story from there.
To actually enter the data for a specific resource element, you click on the datatype in the navigator. In most cases you’ll get a data entry form that displays the options for that datatype on the right pane (and we’ll look at the details shortly) but there are a couple that are worth a more detailed discussion.
If the datatype is a resource reference, then you’ll see an arrow (à) followed by the resource type – all in green. Some resource types (like Observation or CarePlan) are linked to a patient, and some (like Organization or Practitioner) are not.
If the resource type is linked to a patient, then selecting it will display a dropdown of all the existing resources of that type for the current patient, allowing you to select the one you want.
If it is not, then you will get a link that allows you to search for a specific resource of that type (it makes more sense when you try it!)
If the datatype is one that is coded (code, coding or codeableConcept), then you’ll see a text box into which you can enter a search string. After a brief delay, clinFHIR will query the terminology server and return all of the matching concepts from the valueSet that is bound to that element. (you do need to be a bit patient here, as it can take a couple of seconds for the terminology server to process the request and return the filtered subset of concepts).
(In some cases – when the app knows that the valueSet is small, then all the options are displayed as radio buttons. This most often occurs with code data types.)
We’ll talk more about binding valueSets when we discuss profiling, but basically the valueSet that is ‘bound’ to the element contains the list of permissible options for that element. With a profile, we can change the contents of the ValueSet, and hence the options available. If the item you want is not in the valueSet, then you can enter the item as text (though it will no longer be computable of course).
Coded elements have another neat feature: there is a hyperlink called ‘Explore ValueSet’ along side where the search text is entered. Clicking that link allows you to view the ValueSet – and make queries against it to see what it contains.
With the exception of resource references, after you enter the data in the template you need to click the ‘Save’ button to actually to add it to the resource. When you do this, the element will be updated, and the resource that you are building will be displayed in the right pane (in JSON format). This is a great way to see what the FHIR resource actually looks like. The element in the navigator will also have a tick against it – useful as you can see at a glance what you’ve entered so far.
Some of the datatypes have the phase ‘Show Child’. These occur when the element is a ‘complex’ element – ie it contains a number of ‘child’ elements rather than a single datatype – for example like Condition.stage or Condition.evidence. (Oh, and this is a known bug at the moment – condition.stage has a multiplicity of 0..1, which confuses the app as it expects these to be 0..*)
If you click on one of these, then the navigator will show these child elements in the same format as the main display, and the ‘breadcrumb’ above the navigator will show that you are in a child element rather than the main one (you can click in the breadcrumb to return to the main branch).
If you look in the right pane, you will see 2 buttons – one with the number ‘1’, and the other a ‘+’ symbol. This is how you can create multiple ‘instances’ of the child element – and move between them when you have more than one (it is also why Condition.stage confuses the app – it can only have a single child.) Note that if you create multiple child elements, there is (currently) no way of deleting one.
Once you have entered all the data you want to enter against the resource, it’s time to save it on the server. On the bottom right is a button labelled ‘Save Resource’. Clicking that will load a confirmation screen that has the JSON representation of the resource. It also will display any errors that are detected – such as required fields that are missing. Once you’re sure the resource is complete, click Save. The resource is saved to the server, and it’s full ID (which will look something like http://fhir-dev.healthintersections.com.au/open/Condition/160/_history/1 )
You can type this ID directly into a browser (or even better a browser plug-in like Postman) and you will see your new resource in all it’s glory. But there’s a better way to do this – which we will explore in the next post!
Add Comment