August 3, 2015 1 Comment
July 26, 2015 1 Comment
In the previous post, we outlined our plans for creating a profile against the Patient resource, and manually created and saved some of the supporting resources (ValueSet and our NamingSystem) that we’re going to need.
Next up is the extension definition and the actual profile against Patient. Once we’ve done that (which is the topic of this post) we can actually create conformant resources.
Fortunately, we can use clinFHIR to create these artifacts, so start up that application and select the ‘profile builder’ from the front page. (And a reminder that this is very much ‘beta’ software designed for training! Let me know of any issues)
July 26, 2015 5 Comments
One of the things we discussed at the recent seminar in New Zealand was profiling FHIR resources. This is where we take the base resources and then adapt them for specific use cases. While quite simple in concept, there are some complexities ‘under the hood’, so part of the talk was to describe some of the ‘infrastructure’ that makes all this work.
Once we had the set up some of the supporting resources, we used the clinFHIR tool to actually assemble the profile, as this makes it easier for ‘non-technical’ people – especially clinicians – to build these artifacts, and then build a resource that is conformant to that profile.
March 3, 2015 2 Comments
A couple of posts on Profiles in the DSTU-2 candidate from the guys at Furore:
These guys have been involved with – and supported – FHIR from the very beginning, are the maintainers of one of the FHIR test servers (Spark) and are also the authors of the reference profile editor (forge) so they know their stuff!
January 1, 2015 7 Comments
Actually, on reviewing the previous post about profiling in DSTU-2, I realize that there is a simpler way of applying extensions to a profile (in addition to the Conformance package). If you look at the Profile resource, it contains 2 main parts:
- Metadata about the Resource/Datatype being profiled (name, identifier publisher etc) plus the name of the resource and a link to the base profile that is being modified (eg the profile that describes the core resource in the spec).
- A collection of elements (of type ElementDefinition) each of which describes one of the elements/properties within the resource.
(To be precise, there are 2 collections of elements in the profile:
- The differential – which describes the difference between the base profile
- The snapshot – which describes the profiled resource completely
the reason for the two is to support tooling – we’ll focus on the snapshot for now).
December 31, 2014 1 Comment
As we mentioned in the previous post, profiles have changed significantly in the next DSTU.
Profiling is a really important part of FHIR. The resource themselves are designed to be quite generic ‘building blocks’ that can be used in many different contexts. If you take a look at one, you’ll notice that almost all of the properties are optional and even where coded properties have Terminologies assigned to them, these are often quite ‘loose’ and designed to be amended by a Profile