Re: Digest for hapi-fhir@googlegroups.com - 1 update in 1 topic

42 views
Skip to first unread message

Panayiotis Savva

unread,
Apr 8, 2023, 6:37:32 AM4/8/23
to HAPI FHIR

On Sat, Apr 8, 2023, 12:58 <hapi...@googlegroups.com> wrote:
Joost Van Averbeke <joost.van...@gmail.com>: Apr 07 06:42AM -0700

I am creating a HAPI FHIR Plain Server.
I manage to implement FHIR resource providers such as Patient, Encounter,
...
 
But I also want to be able to process FHIR Bundles of type transaction.
When I try to execute a "create" with a Bundle message to the HAPI Test
Server (R4 FHIR)
(http://hapi.fhir.org/resource?serverId=home_r4&pretty=false&_summary=&resource=Bundle),
I get the message:
 
Warning!
Error: HTTP 422 Unprocessable Entity: HAPI-0522: Unable to store a Bundle
resource on this server with a Bundle.type value of: transaction. Note that
if you are trying to perform a FHIR transaction or batch operation you
should POST the Bundle resource to the Base URL of the server, not to the
/Bundle endpoint.
 
Indeed when a post the FHIR Bundle message of type transaction to the root
URL (http://hapi.fhir.org/baseR4), my bundle is treated successfuly.
"response": {"status": "201 Created", ...}
 
I conclude that I should not use the Resource Providers and Plain Providers
mechanism
(https://hapifhir.io/hapi-fhir/docs/server_plain/resource_providers.html)
to process incoming bundles of type transaction.
 
What kind of HAPI FHIR mechanism, should I use?
 
Could you give me some guidance on to start my HAPI FHIR implementation?
I googled around but couldn't find any starting point.
 
Thanks in Advance
 
Joost
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to hapi-fhir+...@googlegroups.com.

Panayiotis Savva

unread,
Apr 17, 2023, 6:09:01 AM4/17/23
to HAPI FHIR
I opened this issue for bodysite which we are not able to expand the value set at all on HapiFhir.


I hope this helps in some way or another, we are still looking for a solution, so I'm watching this thread too 

Panayiotis Savva 

On Mon, Apr 17, 2023, 11:57 <hapi...@googlegroups.com> wrote:
Marco Strauch <strauc...@googlemail.com>: Apr 17 01:41AM -0700

Hi,
 
I am trying to validate an Observation of profile ISiK blood pressure
having a snomed-ct code for the body site.
 
Here is the example provided by ISiK.
 
{
"resourceType": "Observation",
"id": "ISiKBlutdruckExample",
"meta": {
"profile": [

"https://gematik.de/fhir/isik/v2/VitalwerteUndKoerpermasse/StructureDefinition/ISiKBlutdruck"
,

"http://fhir.de/StructureDefinition/observation-de-vitalsign-blutdruck"
]
},
"category": [
{
"coding": [
{
"system":
"http://terminology.hl7.org/CodeSystem/observation-category",
"code": "vital-signs",
"display": "Vital Signs"
}
]
}
],
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "85354-9",
"display": "Blood pressure panel with all children optional"
}
],
"text": "Systolischer und Diastolischer Blutdruck"
},
"component": [
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8480-6"
}
]
},
"valueQuantity": {
"system": "http://unitsofmeasure.org",
"value": 107,
"code": "mm[Hg]",
"unit": "mmHg"
}
},
{
"code": {
"coding": [
{
"system": "http://loinc.org",
"code": "8462-4"
}
]
},
"valueQuantity": {
"system": "http://unitsofmeasure.org",
"value": 60,
"code": "mm[Hg]",
"unit": "mmHg"
}
}
],
"status": "final",
"subject": {
"reference": "Patient/AYczIkDmA.CdsOkJZEio"
},
"effectiveDateTime": "2012-09-17",
"interpretation": [
{
"coding": [
{
"code": "L",
"system":
"http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",
"display": "low"
}
],
"text": "Below low normal"
}
],
*"bodySite": {*
* "coding": [*
* {*
* "code": "368209003",*
* "system": "http://snomed.info/sct",*
* "display": "Right arm"*
* }*
* ]*
* }*
}
 
The problematic part is the "bodySite" coding. This is not specially
profiled by ISiK but by FHIR. This Coding must use the "ValueSet
'SNOMEDCTBodyStructures'" specified by FHIR R4. This value set includes
all codes were concept IsA 442083009. In the ISiK example the code is below
the given concept and shall be correct.
 
So now lets come to my problem:
 
When I am using the *DefaultProfileValidationSupport* in combination with
the *InMemoryTerminologyServerValidationSupport* this Body Site Code will
be ignored during validation because the content of the loaded code system
is "*Not-Present*".
 
For the method "*isCodeSystemSupported*" the
*DefaultProfileValidationSupport* will always return "false" and then the
code system is being fetched by the
*InMemoryTerminologyServerValidationSupport* using the loaded code System
list of the *DefaultProfileValidationSupport* and then checks if the
content is "*not-present*" then return *false* for "*isCodeSystemSupported*"
 
[image: Screen 1.jpg]
 
So in that case the snomed-ct code is not being validated and no validation
error occurs.
 
 
But I am getting another validation result when I use the
*NpmPackageValidationSupport* (what is a derivation of
*PrePopulatedValidationSupport*) in combination with the "
*InMemoryTerminologyServerValidationSupport*".
Using the *NpmPackageValidationSupport* I load all NPM Packages for ISiK,
HL7-FHIR-DE and fhir-core-r.4 and put it togheter with the *InMemoryTerminologyServerValidationSupport
and the "**SnapshotGeneratingValidationSupport**" into the
ValidationSupportChain*.
 
Now when the validation is checking if the codesystem exists using "
*IValidationSupport.**isCodeSystemSupported*" the "
*PrePopulatedValidationSupport*" will always return true if the code system
was loaded by the definitions of the package. So the *fetchCodeSystem* of
the "*InMemoryTerminologyServerValidationSupport*" will not be used.
But "*isCodeSystemSupported*" will not check the value of content for "
*not-present*". So the code of the snomed-ct system will now be checked and
follow validation error is being returned.
 
{
"resourceType": "OperationOutcome",
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics":
"Validation failed für \"http://snomed.info/sct#368209003\"",
"location": [
"Observation.bodySite.coding[0]",
"Line 1, Col 859"
]
}
]
}
 
[image: Screen 2.jpg]
 
So there is a different handling when using the "
*NpmPackageValidationSupport*" insteadof the "
*DefaultProfileValidationSupport*". Is that intentional or a bug?
 
 
And my last question is. How can I enforce that the code of the body site
will be validated correctly?
Because ISiK and FHIR do not provide the specific snomed codes for valid
values of the given value set and I have not found a validator than can
validate against the snomed conecpt code.
 
I hope someone can help me and bring light into darkness.
 
 
Regards
 
Marco
Reply all
Reply to author
Forward
0 new messages