Stream: netherlands
Topic: Gaps between FHIR nl-core-patient and HCIM/ZIB model
Dave Franken (Sep 18 2018 at 09:37):
Dear FHIR specialists,
I am currently working on trying to implement the HCIM / ZIB (2017) with the FHIR nl-core-patient resource and noticed there are several gaps, for instance:
- FHIR specifies Patient Name as 0..*, while HCIM has it as 1..1
- HCIM has "first names", but FHIR does not have an extensions for this at http://hl7.org/fhir/valueset-name-part-qualifier.html
I feel that a lot of work still needs to be done to align FHIR with HCIM (or the other way around).
What is the proper route to address and resolve these issues?
Is there a committee we could take part in?
Kind regards,
Dave Franken
Meddex
Marc de Graauw (Sep 19 2018 at 07:37):
Hi Dave,
The Dutch HL7 Working Group Meeting is the place to be to discuss this:
https://www.hl7.nl/events/events/intern/bijeenkomsten/10e-hl7-nederland-working-group-meeting-8-9-november-2018.html
I can recommend being there if you're actively involved in ZIBs and FHIR.
There's also the HL7 FHIR Core Team, however that's for active HL7 members (a route which is open to all, of course).
For 'voornamen' vs 'roepnaam' etc, those are all FHIR given names, with qualifiers.
See: https://simplifier.net/NictizSTU3-Zib2017/nl-core-humanname under 'given'. My guess is 'voornamen' are given names without qualifiers, say the default case.
About the first name, looks like you're right. Disclaimer: I did not design the ZIBS nor the FHIR implementation, @Alexander Henket and @Marten Smits would know the details.
Alexander Henket (Sep 19 2018 at 09:30):
Hi Dave. As Marc mentioned you may bring your input to the HL7 WGM NL. As for the specific differences you found:
-
Patient.name has not been made required in the profile because there will be use cases (currently not covered by the zib) that don't require the name. Leaving it optional would still make the zib implementable. Presumably you could create a profile-on-profile to add that extra requirement. We generally did not go there just yet until we know our base is stable
-
Patient.name has a datatype level profile nl-core-humanname. You will find all the extensions we deemed necessary. Since "given" is a core element meant for given names, there's really no need to further qualify that unless you want to mark it as "initials" for example. If you don't qualify HumanName.given, the semantics are already that these concern first/given names.
Note that the Patient profile has been in existence since 2016 and has already undergone various rounds of input. It has even been approved by the FHIR Council/Validation Team. It doesn't mean we cannot update it, though...
Dave Franken (Sep 19 2018 at 14:35):
Thanks for your replies, Marc and Alexander, I will (try to) attend the WG meeting to address these issues. We have found many more gaps, so maybe we can create/share an issue list with our findings.
Dave Franken (Sep 21 2018 at 13:16):
Is there any definitive description for the basic datatypes found at https://zibs.nl/wiki/Beschrijving_en_gebruik_datatypes?
There are some vague references to ISO and/or HL7 R1. For instance II refers to the type uid, but the type uid is not described on that page.
Michael van der Zel (Sep 21 2018 at 16:18):
Here is the (dutch) description https://www.registratieaandebron.nl/pdf/Architectuurdocument_Registratie_aan_de_bron_-_Volume_1_v1.1.pdf page 12. But I see now that refers back to the wikipage.
Michael van der Zel (Sep 21 2018 at 16:22):
We made a mapping from the conceptual/logical ZIB datatypes to the FHIR datatypes and applied that in the FHIR versions of the ZIBs. E.g. II in the ZIB is Identifier in FHIR.
Does that answer your question @Dave Franken ?
Dave Franken (Sep 24 2018 at 07:29):
We made a mapping from the conceptual/logical ZIB datatypes to the FHIR datatypes and applied that in the FHIR versions of the ZIBs. E.g. II in the ZIB is Identifier in FHIR.
Does that answer your question @Dave Franken ?
If you look at https://zibs.nl/wiki/Beschrijving_en_gebruik_datatypes there is a note "All these datatypes should be mappable to ISO 21090 or HL7 R1 DT or...", the ellipsis is actually there, so it's rather vague. That diagram is also incomplete as it references types not defined there, such as Uid and CS. I found http://www.hl7.org/implement/standards/product_brief.cfm?product_id=48 and kind of went from there, but those datatypes are way more extensive than the HCIM ones.
So it would be nice if there was a detailed description of these datatypes that either references a concrete set or defines everything without HL7 / ISO.
Note that the Architecture document is also not very helpful here.
Michael van der Zel (Sep 24 2018 at 08:06):
I am still not clear on what you want to do. If you want to use implantable artifacts of the ZIB's, namely the CDA templates or FHIR profiles, you don't have to bother about the ZIB datatypes, because they have already been converted to CDA datatypes or FHIR datatypes respectively. I do agree we should explain this better in the architecture document!
Dave Franken (Sep 24 2018 at 08:22):
I am still not clear on what you want to do. If you want to use implantable artifacts of the ZIB's, namely the CDA templates or FHIR profiles, you don't have to bother about the ZIB datatypes, because they have already been converted to CDA datatypes or FHIR datatypes respectively. I do agree we should explain this better in the architecture document!
My goal is to create a model in code that is neither dependent on CDA, FHIR or any other concrete implementation, just the basics so that they can be converted to/from whatever format it needs to be in. That is currently pretty difficult, because of these gaps in the datatype descriptions.
Also I noticed some inconsistencies, such that Patient has attribute ContactInformation with cardinality 0..1, but HealthcareProfessional has this attribute with cardinality 0..*.
I wanted to make a request on https://bits.nictiz.nl/secure/Dashboard.jspa, but I don't have an account nor any idea how I could get one.
Dave Franken (Oct 02 2018 at 10:21):
I am still not clear on what you want to do. If you want to use implantable artifacts of the ZIB's, namely the CDA templates or FHIR profiles, you don't have to bother about the ZIB datatypes, because they have already been converted to CDA datatypes or FHIR datatypes respectively. I do agree we should explain this better in the architecture document!
Michael, there are a lot of weird translation quirks as well. For instance, ZIB calls the "CD" datatype a "Coded Descriptions", while ISO 21090 calls it a "Concept Descriptor", HL7 v3 uses the term "Concept Descriptor" as well. There is absolutely no consistency.
ZIB choose one of two routes:
- Use an existing standard as a reference for its datatypes (perhaps restricting the attributes), such as ISO or HL7
- Describe its own datatypes fully and without anchoring it in an existing standard, perhaps using an existing standard as a starting point, but not as a definitive source
Alexander Henket (Oct 02 2018 at 10:30):
It was my understanding that the ZIB datatypes were originally thought of as comparable to the DCM datatypes that match ISO 21090 or HL7 Datatype R2. Those are essentially the same. I later learned that I should not look at the datatypes in the ZIBs like that, and should expect them to be on their own but with a strong root in aforementioned standards.
Nonetheless CD == Concept Descriptor and I'm inclined to believe that any ZIB page that says otherwise is inconsistent.
@Dave Franken I've requested a BITS account for you. You are on CC of that request. Thank you for bringing your issues forward.
Dave Franken (Oct 02 2018 at 11:01):
@Alexander Henket , DCM is a relatively new term for me. From what I can find about it, DCM is just an underlying standard describing how you could create a concrete healthcare model. But DCM itself does not define any datatypes. See also this post I found: https://wolandscat.net/2011/09/11/dcm-data-types-and-reference-model-considerations/
I am okay with any direction that ZIB chooses, as long as it is consistent and well defined. I think aligning with or using (a restricted version of) ISO is definitely a decent option. A lot of these datatypes are very common, so maybe it needs to be done on another level (maybe in a DCM Reference Model itself) such as is suggested by the blog post I mentioned.
Alexander Henket (Oct 02 2018 at 11:04):
@Michael van der Zel would be the best person to comment on the state of affairs around the ZIB datatypes. I can only attest to how I've perceived them so far
Ewout Kramer (Oct 02 2018 at 12:57):
@Dave Franken , you could find out more here: https://www.iso.org/standard/62416.html. Though that's a payed-for thing on ISO. Google's probably your friend here to find a draft version.
Michael van der Zel (Oct 02 2018 at 13:30):
@Dave Franken: DCM is a concept. There is an ISO standard for it called ISO13972. At HL7 we created a UML implementation of those specs (it is here https://gforge.hl7.org/gf/project/dcm_ea/frs/) and with Registratie aan de Bron we further constrained that (documented at zibs.nl) and worked on how to implement them in EHR's and FHIR and CDA specs from them.
There are a lot of "manifestations" of DCM's. There are OpenEHR Archetypes, CDA templates, FHIR resources/profiles, CEMs (Clinical Element Models, Intermountain Healthcare), CCMs (Clinical Content Models Korea), CIMI models, ... Regretfully they not all have the same datatypes, but conceptually the datatypes are the same.
We could meet to further discuss?
Alexander Henket (Oct 02 2018 at 13:48):
Not sure about the regretful part. CDA/FHIR and DCM are not on the same layer. The models should map, not necessarily be the same
Dave Franken (Oct 03 2018 at 08:09):
@Dave Franken: DCM is a concept. There is an ISO standard for it called ISO13972. At HL7 we created a UML implementation of those specs (it is here https://gforge.hl7.org/gf/project/dcm_ea/frs/) and with Registratie aan de Bron we further constrained that (documented at zibs.nl) and worked on how to implement them in EHR's and FHIR and CDA specs from them.
There are a lot of "manifestations" of DCM's. There are OpenEHR Archetypes, CDA templates, FHIR resources/profiles, CEMs (Clinical Element Models, Intermountain Healthcare), CCMs (Clinical Content Models Korea), CIMI models, ... Regretfully they not all have the same datatypes, but conceptually the datatypes are the same.
We could meet to further discuss?
I'm going to make a ticket at the issue tracker to request a better and definitive description of the datatypes. As I said, it doesn't matter much where they come from, I just believe that they should be defined independently from any implementation. We could use ISO 21090 as a starting point, that makes sense. We just have to ask ourselves if we want to restrict those datatypes, because the ISO types generally have a lot more attributes than we might need.
Michael van der Zel (Oct 03 2018 at 14:10):
Not sure about the regretful part. CDA/FHIR and DCM are not on the same layer. The models should map, not necessarily be the same
Ow, sorry. "Regretfully" was not the right word. I meant to just say that it is a fact that they use different datatypes, because they act on different layers.
Last updated: Apr 12 2022 at 19:14 UTC
