Stream: cimi
Topic: mapping
Michael van der Zel (Jun 22 2017 at 04:53):
Ok. Let's get started.
I think that the CIMI FHIR Resource Profile SHALL map back to the CIMI FHIR logical models. What should be the requirements?
Grahame Grieve (Jun 22 2017 at 20:35):
I think they should. Convertably?
Jay Lyle (Jun 26 2017 at 12:24):
Does that mean that we use a CIMI archetype first to generate a FHIR logical model and then generate a FHIR profile from there? What does the extra step buy?
Grahame Grieve (Jun 26 2017 at 12:58):
which extra step? the archetype or the logical model?
Jay Lyle (Jun 26 2017 at 15:11):
The archetypes come from CIMI. The profile is the goal. So I see the logical model as an additional step. Could be necessary, but I don't know why.
Grahame Grieve (Jun 26 2017 at 20:56):
it's primarily a technical thing - a staging point. From the point of view of administering the journey, it's helpful, in that's the intent of the archetype restated in FHIR language, before dealing with the heavy lifting of the mapping.
Grahame Grieve (Jun 26 2017 at 20:56):
having that intermediate has all sorts of tooling benefits
Grahame Grieve (Jun 26 2017 at 20:57):
I understand the question you are asking as 'how useful is that intermediary step to end-users'. And my answer is, that depends on their skills and background. For someone with CIMI exposure, the answer is probably, not very much - there's not much to learn from restating the same thing in a different format.
Grahame Grieve (Jun 26 2017 at 20:58):
but for someone with a FHIR background.... it'll make much more sense
Grahame Grieve (Jun 26 2017 at 20:59):
My experience of converting from archetypes to logical models is that the FHIR binding to terminology is much more precise than the archetype syntax, and the minimum expectations are much higher - archetype editors generally don't use the syntax they have to be specific about terminology, and the FHIR logical model conversion actually requires some heavy lifting around getting the terminology binding correct. and this means that the logical model itself says some new things
Grahame Grieve (Jun 26 2017 at 21:00):
but that's driven by style and policy, and I expect CIMI will be getting the terminology bindings correct in the source model. (And I strongly advise CIMI to do so, should that not be the case)
Jay Lyle (Jun 27 2017 at 12:36):
I expect the CIMI archetypes to get the terminology right -- that's the idea, anyway. Another point of CIMI is to be platform independent, so we wouldn't want to make FHIR logical modelling a requirement for all transforms. (Though we might.) But making it part of the FHIR transform may be exactly right. As you say, sounds like a design decision.
Grahame Grieve (Jun 27 2017 at 13:38):
in principle, the FHIR Logical model should be iso-morphic with the archetype. So it's a style issue how you do your content
Grahame Grieve (Jun 27 2017 at 13:38):
should be
Richard Esmond (Jun 28 2017 at 21:52):
It would be my understanding of the CIMI goals relative to terminology binding:
1) Was sufficient to produce FHIR Profiles that weren't deficient in comparison to other methods
2) Achieve alignment with the cross-family terminology binding guidelines being produced in the Vocab group
3) Provide necessary binding semantics to cope with DL and Non-DL based terminologies (such as LOINC, RxNorm, ICD-10, etc)
So, I would expect that whenever a gap was discovered between the binding capability of FHIR and CIMI, that would be something the group would want to identify and correct.
Do others feel differently about this?
Richard Esmond (Jun 28 2017 at 22:04):
The biggest question I always ask myself relative to Iso-morphic transforms between Archetypes and FHIR is one of granularity. The FHIR world seems to want a much smaller number of Profiles which use optionality and flattening to reduce the total count.
If we use Fractures as an example. The CIMI Fracture Hierarchy would wind up with 100+ detailed clinical models (DCMs) which would themselves be composed of small reusable bits, which might contain several layers of more abstract ancestors. But it isn't hard for me to imagine that with a bit of gap analysis it would be possible for those 100+ individual archetypes to be transformed to FHIR Logical Models and then back to Archetypes without loss. But usually that isn't what people are talking about when they talk about iso-semantic transforms between FHIR and CIMI.
Most of the conversations about transforming CIMI into FHIR involve creating a schematic-anchor at some parent point and aggregating a larger number of DCMs below that point to create a single FHIR Profile that can transport an entire 'class' of DCMs. An example might be going to far, but what if a single FHIR Profile were created for all Fractures, with optionality being used when certain data-elements only applied to a subset of the bones. (Sagittal / Distal, Etc. ) Flattening would also often be employed during this transform.
And this type of aggregation and flattening isn't particularly conducive to round-trips.
So my question to the FHIR community is:
Who tolerant is the community going to be to large numbers of very definitive FHIR Profiles vs. wanting smaller numbers of less definitive ones?
Grahame Grieve (Jun 29 2017 at 13:20):
well, that's a good question. my general view, which I've stated a number of times, is that 100s of variant models is a no-go. You have to establish regularity, and move the hyper-variance into terminologies.
Grahame Grieve (Jun 29 2017 at 13:20):
the key difference that makes is the tabular format; there's a limited amount of structural variance.
Grahame Grieve (Jun 29 2017 at 13:21):
I think that the current CIMI approach that ignores this concern is never going to penetrate into real software systems
Grahame Grieve (Jun 29 2017 at 13:21):
at least, that's my opinion. What the community will accept... that's as yet undetermined
Grahame Grieve (Jun 29 2017 at 13:22):
you're right that the interconversion between archetype and FHIR Logical model is neither here nor there in this respect; it's just a syntax etc change.
Ewout Kramer (Jun 30 2017 at 11:15):
I think that's correct. It's natural for software enigneers to look at such a bunch of profiles and look for structural commonalities, which leads to common features of the implementing software (e.g. same database tables, same classes) Having hundreds of them means a big effort in finding these commonalities. This leads me to think that even though there may be reasons to logically create multiple cimi artifacts (because the modelled concepts are logically different), software engineers care more about structurally differences. Which will lead to a different opinion on when to create a new model, and when to combine two models in one.
Michael van der Zel (Jul 05 2017 at 11:03):
Another thought. Maybe the detailed CIMI models are actually (partial) example instances of some common structure.
I also would really like the requirement stated that the CIMI FHIR Profiles SHALL populate the <mapping> back to the original CIMI archetypes. We need computable traceability from implementation back to specification, so you can automatically check progress and conformance/compliance to specs.
Richard Esmond (Jul 05 2017 at 18:00):
I wish I could disagree with Grahame about the broader EMR communities desire for less variance, but it's going to be a long while before highly dynamic systems evolve that are less impacted by highly complex schemas. We have databases that do well with dynamic and complex schemas, but we don't have any EMR / healthcare systems built on top of them. Over-time I personally suspect we will see many more of these, but not overnight.
But when you enter the realm of the niche focused platforms, such as the one from my parent company PenRad, that is where you see a high payback for complex and highly computable schema. PenRad is only sold to Breast Imaging centers and used solely by breast-focused Radiologists, so its worth it to have two dozen tables with 60-70 different value-sets which contain around 650 individual concepts.
And the Oncologists, Pathologists and Surgeons down-stream are very interested in the rich and computable data-stream. But I suspect that we would be waiting a very long time before a mainstream EMR vendor was interested in adopting two dozen profiles solely for breast reporting.
One last comment on per-coordination:
We will be needing to author new SNOMED Concepts - somewhere in the few-hundred range if we rely on the information model and post-coordination fields. If we were to produce all the combinations necessary to avoid post-coordination in the information model, we would be looking at thousands just for breast. So, I'm not sure that pre-coordination is that much more practical. This is the stuff that keeps me up at night. (LOL)
Grahame Grieve (Jul 06 2017 at 20:59):
@Michael van der Zel agree about the mapping backwards.
Grahame Grieve (Jul 06 2017 at 21:00):
@Richard Esmond It's not a technology thing. It's about how people think. 1 table with 1000 rows has 1/1000th of the complexity of 1000 tables with 1 row. (technology may magnify the problem, but can't reduce it)
Last updated: Apr 12 2022 at 19:14 UTC
