New profile added for lab#6
Conversation
michal-ciszewski
commented
Sep 16, 2025
michal-ciszewski
commented
- lu-OrderData profile based on ServiceRequest added
- ValueSet Aanvraagstatuscodelijst added
- ConceptMap to translate values from Aanvraagstatuscodelijst to HL7 Request Status ValueSet
- adjusted dates in capability statements
- adjusted versioning of the profiles
…tions, moved mapping for the Comment from ServiceRequest.note to ServiceRequest.note.text, some adjustments to the definitions
…n capability statements
…ng, format in capabilityStatements ammended in order to comply with the validator
…nstraint dom-6 (done according to the profiling guidelines)
…tect a capitalization as a change)
…ub (solution based on the example from official FHIR docs)
…atement validator)
michal-ciszewski
requested review from
DanielPuettmann
and removed request for
pieter-edelman-nictiz
DanielPuettmann
left a comment
DanielPuettmann
left a comment
There was a problem hiding this comment.
If you can answer my questions (and change that one canonical), you are good to go!
| <format value="xml"/> | ||
| <format value="json"/> | ||
| <format value="application/xml"/> | ||
| <format value="application/json"/> |
There was a problem hiding this comment.
Why add the application/ and why not expand to application/fhir+xml or application/fhir+xml?
There was a problem hiding this comment.
Yeah, I had problems with the validator here over this issue. I tried fhir+xml at some point, and it didn't work. I'm gonna try it again now that the validator is updated
There was a problem hiding this comment.
changed and works now
| <code value="11502-2"/> | ||
| <display value="Laboratory Report" /> | ||
| </fixedCoding> | ||
| </patternCoding> |
There was a problem hiding this comment.
Isn't this always a Laboratory Report? Why change this into a patternCoding when a different code would change the meaning of the resource? see: https://informatiestandaarden.nictiz.nl/wiki/FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Values_that_should_be_present_verbatim
There was a problem hiding this comment.
I think based on that specific chapter it should be pattern, since Coding is a complex datatype. I made coding.system required to follow the guideline.
There was a problem hiding this comment.
I think putting the code on .fixed rather than .pattern hinges on whether:
- You expect users to use a different LOINC code to show that their FHIR instance is a laboratory report.
- You can accept that you will not be able to identify these FHIR instances by their coding.
If you these two things are okay for you, you should go ahead with the profile as-is! 👍
There was a problem hiding this comment.
I understand that perspective. From that point of view, I would definitely prefer to have fixedCoding, but I do have to take into account our general approach to profiling: the profiled value is a minimum expectation and other additional values are still allowed. I do see it as a compromise: we cannot be too restrictive (making it a bit less handy), but at least that one specific LOINC code 11502-2 has to be one of the codes in any FHIR instance.
| <alias value="Vraagstelling" /> | ||
| <binding> | ||
| <strength value="required" /> | ||
| <valueSet value="https://decor.nictiz.nl/fhir/4.0/zib2020bbr-/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.7--20200901000000?_format=json" /> |
…Statements and reversing to fixedCoding in lu-Composition (based on review van Daniel)
…nally constraining cardinality of coding.system.
DanielPuettmann
left a comment
DanielPuettmann
left a comment
There was a problem hiding this comment.
If you can answer my questions (and change that one canonical), you are good to go!
3 participants
