There are many times when you aren't quite ready to adopt a new release, either because it isn't fully baked yet (as for FHIR STU3), or you just aren't ready to suck up a whole release in a development cycle to get the ONE feature you would really like to have.
The FHIR Extension mechanism is a way that you can add new stuff to an existing FHIR release. But how should you use it for problems like those described above?
I'm going to be playing with this in the near future because I have some STU2 stuff going on right now, but I really need some of the fixes to Coverage in STU3. Right now, STU2 talks about subscriber*, but doesn't actually link the coverage to the member (the actual patient being treated)! STU3 fixes that, and I want to preadopt the fix.
So, how am I going to handle my extensions? Well, first of all, for every field I add, what I want to do is to name it using the STU3 (Draft) URL (and later to the STU3 URL). So my extension URL becomes something like http://hl7.org/fhir/2016Sep/coverage-definitions.html#Coverage.beneficiary_x_, and bang, I have a referenceable URL that pretty clearly defines the extension.
What does FHIR say about that?
The
Apparently what I've done isn't quite right because it doesn't follow the FHIR rules (even though it follows the spirit) of FHIR requirements for extensions. Right? So, NOW what? Somehow we need to give each extension a name.
Actually, let's see what happens when I plug StructureDefinition into this equation. I now get:
http://hl7.org/fhir/2016Sep/StructureDefinition/Coverage#Coverage.beneficiary_x_. Click the link to open where that goes in a new window. Dang! Pretty fricken close. StructureDefinition/Coverage produces a redirect that goes to fhir/coverage.html instead of fhir/2016Sep/coverage.html. So close.
In fact, that's nearly close enough for me. It seems that if we were to fix the redirect problem on the HL7 Server, this would do exactly what I need. Note: It's NOT a structure definition that defines an extension, its a structure definition that defines a resource. But really? Do I have to point you to a structure definition that defines it AS an extension? Or can I just do the nearly right thing and get away with it.
I may want to adopt a resource that doesn't even exist yet. Say I want to use some clinical decision support, but I've invested a bit already in Argonaut stuff based on STU2. How do I handle that? Fortunately, FHIR has the Basic resource, but I'm going to need to extend the heck out of it. No problem, I just use the same technique, with gusto, and even better, I could put some automation behind it to populate my stuff. And so could anyone else.
I wonder what Grahame will think about this?
Keith
The FHIR Extension mechanism is a way that you can add new stuff to an existing FHIR release. But how should you use it for problems like those described above?
I'm going to be playing with this in the near future because I have some STU2 stuff going on right now, but I really need some of the fixes to Coverage in STU3. Right now, STU2 talks about subscriber*, but doesn't actually link the coverage to the member (the actual patient being treated)! STU3 fixes that, and I want to preadopt the fix.
So, how am I going to handle my extensions? Well, first of all, for every field I add, what I want to do is to name it using the STU3 (Draft) URL (and later to the STU3 URL). So my extension URL becomes something like http://hl7.org/fhir/2016Sep/coverage-definitions.html#Coverage.beneficiary_x_, and bang, I have a referenceable URL that pretty clearly defines the extension.
What does FHIR say about that?
The
url SHALL be a URL, not a URN (e.g. not an OID or a UUID), and it SHALL be the canonical URL of a StructureDefinition that defines the extension.Apparently what I've done isn't quite right because it doesn't follow the FHIR rules (even though it follows the spirit) of FHIR requirements for extensions. Right? So, NOW what? Somehow we need to give each extension a name.
Actually, let's see what happens when I plug StructureDefinition into this equation. I now get:
http://hl7.org/fhir/2016Sep/StructureDefinition/Coverage#Coverage.beneficiary_x_. Click the link to open where that goes in a new window. Dang! Pretty fricken close. StructureDefinition/Coverage produces a redirect that goes to fhir/coverage.html instead of fhir/2016Sep/coverage.html. So close.
In fact, that's nearly close enough for me. It seems that if we were to fix the redirect problem on the HL7 Server, this would do exactly what I need. Note: It's NOT a structure definition that defines an extension, its a structure definition that defines a resource. But really? Do I have to point you to a structure definition that defines it AS an extension? Or can I just do the nearly right thing and get away with it.
I may want to adopt a resource that doesn't even exist yet. Say I want to use some clinical decision support, but I've invested a bit already in Argonaut stuff based on STU2. How do I handle that? Fortunately, FHIR has the Basic resource, but I'm going to need to extend the heck out of it. No problem, I just use the same technique, with gusto, and even better, I could put some automation behind it to populate my stuff. And so could anyone else.
I wonder what Grahame will think about this?
Keith
P.S. * Also broken as defined in STU2, and not yet fixed in STU3 because I am not a patient at my wife's OB/Gyn practice, nor am I a patient at my children's Pediatric practice, but they clearly have me on file as some sort of RelatedPerson. There's already a tracker for this.
No comments:
Post a Comment