Stream: conformance
Topic: Push-back against Profiles
Grahame Grieve (Nov 21 2019 at 12:46):
@Kevin Mayfield
this is where push back starts, the profile is obscuring the requirement.
I'm always interested in improving the way we present profiles, and this actually seems like a presentation issue.
Grahame Grieve (Nov 21 2019 at 12:47):
but the IG editors have generally felt that this is part of their responsibility, manually writing a clear summary of the intent of the profile
Kevin Mayfield (Nov 21 2019 at 12:47):
I agree, I'm looking at it from that perspective at the moment.
Kevin Mayfield (Nov 21 2019 at 12:59):
How a developer and modeler approaches the problem is different, one will use start with example resources and the other profiles. The developer may not use profiles directly but indirectly via validation.
Lloyd McKenzie (Nov 21 2019 at 15:00):
The challenge is that there's a need to present information to two stakeholders - the human developer and the software code generator/validator/whatever. The ideal is to have a single source of truth that drives both because then you have minimal likelihood of inconsistencies (which are inevitable if the two versions are maintained separately) or differences in the degree of precision. The challenge is that taking something that is fully specified enough to be computable isn't necessarily easy to render in a way that communicates easily to humans. And this is the first time HL7 has tried to do this with a single source of truth. (CDA had computable rules, but the human representation and the computable representation were still distinct data structures and could - and sometimes did - either become inconsistent or expressed things with different levels of precision.)
Kevin's use-case seems to be principally about "what's changed", which is what the differential view is supposed to do. But perhaps we could come up with a more textified version of that: E.g.
"Telecom: Overall cardinality 0..* -> 0..5.
At least one repetition must be of type phone and include value and type."
In theory we could come up with an algorithm that expresses that meaningfully. Though we run into challenges even here. To someone who's experienced "cardinality 0..* -> 0..5" is redundant as the "cardinality" bit is a given. Repeating it all over is noise. On the other hand, for someone new, it's essential. Do we create different views for the newbie vs. the expert? If we create a single view, what's the right balance of verbosity/conciseness?
I don't think GraphDefinition is going to help for individual resource constraints, but it's almost certainly going to be useful for resource collections.
Kevin Mayfield (Nov 21 2019 at 16:41):
I'm in two minds here, I'm not in favour of doing anything different for FHIR RESTful or Documents.
-
On FHIR Documents and RESTful, comments seemed to be around profiles limiting reuse. That could be the end user seeing the need to produce a resource of type Condition-ABC-1 and Condition-ABC-2 rather than conform to them (so rule rather than OTW format).
-
Other interactions such as messaging, RPC (Hl7v3) style operations and complex models operations maybe where the 'push back' mostly is. I've seen several specifications where a list of profiles has been presented, that doesn't say what should be included (what is in the Bundle response or how it is constructed).
This is response requirement for an RPC Operation I've recently worked with https://project-wildfyre.github.io/conformance/graph/3
The other issue is how would you validate this response, suspect the answer is GraphDefinition.
We should focus on GraphDefinition to document these and then profiles? (plus the GraphDefinition can contain useful summaries of what is being profiled e.g. heart rate SNOMED Concept 364075005 and units /min.)
(am I correct in believing this is how GraphDefinition can be used in R4?)
Grahame Grieve (Nov 22 2019 at 05:34):
I do think that the best approach is
- clearly expressed requirements
- a good balance of use StructureDefinition and GraphDefinition to express requirements
- not using Resource.meta.profile anywhere you can avoid it
The first is the hardest n princple, but the second is impossible right now because the tooling doesn't support GraphDefinition yet. And it looks like GraphDefinition is heading for a big redesign based on today's talk at DevDays
Kevin Mayfield (Nov 22 2019 at 07:47):
From a UK perspective we have primarily focused on profiles and used them to document solutions which is skewing opinions of profiles. Plus many of our projects have been driven by other models, e.g.
- Digital Child Health (FHIR Messaging) - influenced by HL7v2
- GP Connect (FHIR Operation ) - influenced by HL7v3
- NEWS2 (none) - openEHR
- End Of Life Care (FHIR Restful - Structured Data Capture) - national dataset
- Transfer Of Care (FHIR Documents) - CDA
I think the use of GraphDefinition would be split into two: illustrative and rules (inc illustrative). Rules would focus around the structure of the response, e.g.
Response (Bundle) should contain
- 1 Patient (of profile A)
- 1 Encounter (of profile ..)
- 0..3 Observation (of profile ..)
May also rules on references.
For FHIR Documents, these rules would probably be expressed in the Compositions profile, so use of GraphDefinition is illustrative (and optional).
n.b. a couple of our developers suggested they wanted two approaches for validation.
- Operational - Check the Bundle contained the correct resources and light checks on resources
- Testing - As above but thoroughly validate each resource
Lastly should GraphDefinition be renamed? ModelDefinition, ResponseDefinition, BundleDefinition...
Graph implies it's for illustration only.
Grahame Grieve (Nov 22 2019 at 08:04):
really? how?
Kevin Mayfield (Nov 22 2019 at 08:07):
All the developer is seeing is profiles (which goes back to your expressing requirements comments).
Grahame Grieve (Nov 22 2019 at 08:12):
All the developer is seeing is profiles
I think you are saying that GraphDefinition is supported by the tools yet, so it's not real
Kevin Mayfield (Nov 22 2019 at 08:22):
and then being asked to return a 'model' response. (With the exception of FHIR Documents - Transfer Of Care) On most of these 'models', testing has focused around Bundle content and NOT used Validation.
[This is skewing opinion]
Eric Haas (Nov 25 2019 at 18:28):
I think we should stick to GraphDefinition as the best name since graph theory is about defining the relationships and not just the pretty pictures.
Last updated: Apr 12 2022 at 19:14 UTC
