First of all, let’s start with some introductions: My name is Marten Smits, I am Ewout’s colleague, and formerly an intern at Firely. I graduated last July at the University of Amsterdam, where I studied Medical Informatics. Since August, I have been part of Firely, where I have the privilege to work with FHIR full time. As I am typing this, I realize that I have been working with FHIR for over a year now, as it was one of the subjects of my graduation project as well. Wow, time really flies when you are having fun…. Anyway, I will join Ewout in writing blogs about FHIR on The Fhirplace!
In January, Ewout took me to my first HL7 WGM in San Antonio, where some of you may have met me. I have visited many different work groups, which were (almost always) very interesting, and where I learned a lot about the different aspects of HL7 standards. Of course our main interest at the WGM were the FHIR ballot comments. Issues, use cases, solutions, and (if necessary) changes were discussed by the work groups. Some issues were straight forward, and some were very complicated.
All major changes from DSTU-1 were discussed: newly introduced resources, the new JSON format, the introduction of Bundle (in favor of Atom) and many more. To my surprise, there wasn’t much discussion about the changes that were made on Profiles.
Profile: DSTU-1 vs DSTU-2 proposal
If you have taken a look at the Profile resource lately, you will immediately notice the changes that I am talking about.
Here is what the Profile resource looks like in DSTU-1:
The first time I saw that resource I was a little bit scared. This was definitely the most complicated resource in the FHIR specification at the time, and it took me a while to fully understand it. And one the first profiles I created had 13.000 lines of XML…
When I was preparing for the WGM in San Antonio, I took my first good look at the new Profile resource in the development version of FHIR. I first thought there was a bug in the website or that someone made a mistake, because what I saw was this:
I immediately turned around to Ewout (who has his desk right behind me) and I ask him: “Is this really the new profile? Where is all the rest?” He readily explained what happened to rest of the profile resource. I will give you a recap in this blog post!
Why is it so small?
The first thing you have to realize is that Profile is now something completely different than it was in DSTU-1. In DSTU-1 a
Profile resource was something which described all the constraints on Resources, extensions and search parameters that you need in your use case.
The new Profile describes only the constraints of a single resource that you need in your use case. You could say that it is the equivalent of the
Structure part of Profile in DSTU-1, including it’s reference to
Where did the rest of the resource go?
As you probably have noticed, the Profile resource has gotten a lot smaller. Which immediately brings us to biggest change: Profile has been split up in multiple smaller resources:
- Profile (formerly
- ExtensionDefinition (formerly
- SearchParameter (formerly
The motive for splitting up the resource is actually really logical: This makes it easy to reuse the different parts of your Profile, which you could not easily do in DSTU-1. The lifetime of these separate resources are no longer bound together: you can refer to them separately, you can update them separately and you can refer to them like any other Resource. Finally, Profiles in DSTU1 turned out to be huge, so you were downloading a full profile just to get the definition of a single extension.
How do I combine the resources?
Once you have created new (or reused already defined) extensions and profiles. You might still want to combine them in some sort of package, to make sure that everyone who needs to use them knows that these are the rules that you use in your use-case. Just like you did in DSTU-1 with the large Profile resource.
I discussed that with Ewout, because I couldn’t find how to do this in the spec. He told me that FHIR is planning to use the existing
Composition resource for this, where you can put in the metadata of your package, and use
Compositions section structure to reference to different conformance resources. In practice this will look like this:
In this “Conformance Package” you have all the resources you need to describe your use case. As you can see these include far more different types of resources than were available in DSTU1. You can reference to the
ValueSets that are typical for your use case, you can reference to your newly created Profiles (formerly
Structure), and reference to Extensions and Conformance (describing compliance). Among The new DSTU2 conformance resources are
OperationDefinition (describing additional operations on the REST interface), and
NamingSystem (describing identifier or coding systems OIDs and urns in use in your context).
As you probably would have noticed by now I am very excited by this “evolution” of the profile resource. It makes life easier for the people who have to create profiles (or conformance packages), and also for the people who have to implement them. No more 13.000 lines of XML in one file, but smaller resources which can be more easily reused and altered. Now that I’ve almost finished this blog post I realize why there wasn’t any discussion about this major change in San Antonio: Profiling finally just feels right.
The only comment I have is the name. I suggest to name the new Profile resource “ContraintDefinition”, because it has a much smaller scope than the Profile resource in DSTU-1. Now, the name will just confuse people.