Stream: implementers
Topic: Using a Profile or a Bundle or Order.Detail ?
Neil Grooby (Nov 30 2016 at 03:49):
Hi
We are trying to implement a FHIR version of an existing API which allows third parties via their CRM systems (B2B) to request services to be performed - mostly getting historical information, but sometimes requesting procedures to be performed.
We have found that an Order goes only part of the way to providing the API equivalent functionality and we need to supplement this with additional information:
- An authority form (Consent)
- Additional Persons (adviser, case manager)
*External reference information - this will be reflected back to allow cross referencing within their CRM later when information is known.
Looking at Order, we could - Load these additional information into 'Order.Detail' (some data would not be known as a reference, so a contained resource)
- Create our own Profile - this profile would be specific to our company and the CRM integration would be aware of this Profile
- Place Order plus these additional resources info into a Bundle
Due to backward compatibility with the API, we are looking at using FHIR as the main integration to the base storage, then transpose the FHIR resource/profile/bundle into the only API objects - this is primarily to allow existing customers to seamlessly use their existing investment.
Which would be the preferred method ?
John Moehrke (Nov 30 2016 at 17:16):
I can only speak to the Consent... Yes, use the Consent to convey privacy authorizations, advanced directives, and authorizations to treat. These are distinct concepts from the Order, or Careplan, etc...
Grahame Grieve (Nov 30 2016 at 18:41):
have you looked at the current build, at task, and the associated description stuff? Order will be deprecated and replaced with task in FHIR release 3
Jose Montoya (Dec 01 2016 at 00:26):
Where can I find the current build? We were about to start implementing Order, we didn't see anywhere that it would be deprecated.
Grahame Grieve (Dec 01 2016 at 00:27):
Neil Grooby (Dec 01 2016 at 02:37):
Thanks Grahame. I believe our developers are using Spark as a basis for integration which looks to only be at DSTU2.
If we use DSTU2 then we will not be already developing to an old release which is not ideal for a new project.
Grahame Grieve (Dec 01 2016 at 02:41):
release 3 is due late Feb next year
Neil Grooby (Dec 01 2016 at 02:42):
OK, so 3 months away. Are you talking R3 Spark or STU3 being at a maturity level we should use ?
Grahame Grieve (Dec 01 2016 at 02:43):
STU3. You'd have to ask on the dotnet stream what the likely release date for R3 spark is, though I expect it would be fairly close
Christiaan Knaap (Dec 13 2016 at 14:25):
Current public domain Spark will be DSTU2 for the near future. The new Spark (currently in development) will add STU3 support as soon as STU3 is released. The first version of that new Spark will itself be released sometime in Q1, 2017.
If you want further help in developing upon Spark, please send me a PM.
Neil Grooby (Dec 15 2016 at 03:40):
Thanks @Christiaan Knaap - some of our devs who are also on here may contact you.
Last updated: Apr 12 2022 at 19:14 UTC
