Stream: implementers
Topic: Philosophical - to profile or not
Andrew Patterson (Aug 24 2017 at 23:50):
Envisage a theoretical system that is going to orchestrate some lengthy health computation operations. We want to put a FHIR interface up to allow people to put orders and related patient details/observations into our system, and to get the test result/reports back out at the end. So like a lab request/test/report cycle - only not a lab, and greenfield enough that we can think about the interface in FHIR.
So we will be profiling resources to ensure that code systems etc are as we expect. i.e. if we can only process observations with SNOMED codes, then we will not allow observations with other code systems. Given we are the destination system, and we are expecting to process these resources - I think rejecting resources with data we can't understand is justifiable. (correct me if I'm even out of line here).
My broader philosophical question is - do I profile everything else out that we are not interested in? For instance, if we are not interested in interpretation or referenceRange or method of Observation - and would never likely ever understand or process these fields even if they were filled in - is the correct thing to do to profile them down to 0..0 and prevent them ever coming into our system. Or let them be filled in and just ignore them?
I feel I want to profile everything out that has no meaning in our system - we are a destination system that only understand what we understand, not an EMR for general data storage. Thoughts?
Grahame Grieve (Aug 25 2017 at 00:38):
I think it has a lot to do with how you see the system fitting into the eco-system. If the system is very narrow in terms of business context, and you're going to be talking contracts, terms of service, etc before a working system ever enters the picture, and all the trading partners are going to do bespoke development as part of that process, then yes, nail everything down completely.
but if on the other hand, you're a system that's a general part of the wider inter-networks in health, nailing down things you don't care about is just creating road-bumps for any potential trading partners. If the trading partners are patients on the web, those road bumps would probably be insurmountable
in reality, most systems fit somewhere in between these 2 extremes and the answer is somewhere between them too. for each element you nail down, you convert your/someones possible risk to someone else's definite work
Grahame Grieve (Aug 25 2017 at 00:40):
and someone else's definite work then becomes your possible hurdle to get a sale
Andrew Patterson (Aug 25 2017 at 00:45):
Thanks.. I was thinking in terms of trading partners - essentially using profiles to narrow down the scope of their bespokish work i.e. to document exactly what fields we are interested in our system. "Don't fill in field x and y - we are ignoring them".. but I guess taking that up a notch by not just putting that information in an airy fairy document, but actively rejecting resources containing those fields.
Andrew Patterson (Aug 25 2017 at 00:45):
The envisaged system would have a very small set of trading partners
Grahame Grieve (Aug 25 2017 at 00:48):
well, there's no correct answer here... what you do has to match your business strategy
I will say this, though: in practice, I never see people adding additional validation to reject content in exchanges once the system goes live - I only ever see people backing their validation off, and increasing the gracefulness of what they appear to handle correctly. Postel's Law is more powerful in practice than theory, and you ignore it at your peril
Lloyd McKenzie (Aug 25 2017 at 03:06):
One of the challenges with nailing everything down exactly is that it limits the ability for the system to evolve over time - either everyone needs to change simultaneously or those using the new system need to talk to a new endpoint. On the other hand, if the expectation for systems is "ignore what you don't expect" it's easy for some systems to start sending a new data element while other systems continue to adhere to the old rules.
Richard Townley-O'Neill (Aug 25 2017 at 03:33):
To discourage, but not prevent, innovation you could use a profile that adds invariants with severity of "warning".
Andrew Patterson (Aug 25 2017 at 03:36):
So in this spirit, can profiles/structure definitions etc evolve along with a system? Can I start with a profile that removed referenceRange from Observations - but go to version 2 of my profile in a years time, one that perhaps doesn't restrict referenceRange - and do this all on the same endpoints?
(obviously there is a change management problem with existing clients needing to be informed/brought along with the changes - but in terms of code - an existing client would just not be sending the items so would fit in fine).
Or is there an actual explicit profile version immutability implied when I set up a FHIR endpoint?
Grahame Grieve (Aug 25 2017 at 03:37):
you can do that. We've never made any rules at all about what rules apply to changing conformance rules that apply to end-points.
Andrew Patterson (Aug 25 2017 at 03:38):
@Richard Townley-O'Neill - thanks - that might be the way to go.. I was going to give them some sort of test endpoint that they could throw resources at for checking against the profile.. something that just gives them a bunch of warnings might work just as well
Grahame Grieve (Aug 25 2017 at 03:39):
we have made rules about profile identities - there's rules (not yet finalised) about what changes you can make, and just call it a new version of the same profile.
Andrew Patterson (Aug 25 2017 at 03:41):
is loosening a cardinality for an element, 0..0 to 0..1 say, likely to be within the rules - or are we thinking much less broad brush changes like adding some codes? (acknowledging that the rules aren't finalised.. what's the gist I guess?)
Grahame Grieve (Aug 25 2017 at 03:42):
I think the rules are that if an instance was valid against the profile, it still must be. but I'm hazy.... rules are here:
Grahame Grieve (Aug 25 2017 at 03:43):
http://build.fhir.org/versions.html
Grahame Grieve (Aug 25 2017 at 03:44):
but that's orthogonal to your question - you can just change the profiles that your endpoint conforms to if you want. We would never make rules about that - though some implementation guides might do so
John Moehrke (Aug 25 2017 at 11:51):
I understand that what you are thinking is to define a Profile that has the "meaning" of "This is the optimal information we would -like- to receive"; while not defining that the partners MUST reduce their data to that optimal. It would be good if they did, and you have defined the rules they can use. Thus the Profile in this case is not one that would be used for judging real-time data flow; but rather a documentation tool. This is a different perspective on Profile. Most use of Profile is to define the 'minimum acceptable', thus it is used as a bar one must step over. Your case is different, the high-bar under-which the data would pass..... You did however define a classic Profiling thing, that you do want the codesystem in specific cases to be SNOMED. So I see there being two profiles. One is classic minimum specification, the other being the optimal (reduction). I wonder if there is a need to recognize this 'minimal' vs 'optimal' type of Profile? It would certainly be nice for many Research projects, and eventually nice for De-Identification...
Richard Townley-O'Neill (Aug 27 2017 at 23:58):
I like the idea profiles for different uses: minimum, maximal, others.
Distinguishing 'minimal' and 'optimal' profiles probably belongs in conformance statements, as a profile can only know of the designed intent, not its use.
Last updated: Apr 12 2022 at 19:14 UTC
