New examples using Plandefinition and custom operations

[bdc-ehealth]

@costateixeira @LionelCremer @NathanPeeters @JDW2021 @NISN-SMALS

Because airwaves do not compile, (and neither do marker traces on a whiteboard), a quick summary of our meeting on 30/05/2024, and the elaboration in a new set of examples.

Since the signature of Plandefinition.$apply and Plandefinition.$data-requirements ( https://hl7.org/fhir/R4/plandefinition-operations.html ) do not fit the needs of the projects, we revert to custom operations, defined on Plandefinition: https://github.com/hl7-be/pss/issues/27#issuecomment-2126810010, https://github.com/hl7-be/pss/issues/25#issuecomment-2127181531

Operations can be defined on three levels: the level of the system, de level of the resource and the level of the instance. I understood José's proposal to be one or more custom operations (OperationDefinitions) on the level of an instance of the resource Plandefinition, named "Radiology" or "Antimicrobial". The input would always be a Bundle, and the result a Careplan. The contents of the bundle and the Careplan are according to the needs of the project i.e. to be determined.

[bdc-ehealth]

@LionelCremer @NathanPeeters @NISN-SMALS

A quick summary of the structures that we will set up in the examples according to the contents of the meeting above:

https://teams.microsoft.com/l/message/19:meeting_N2Q1YzQ1MzgtZDFjYy00ODU1LWFiMGYtYmRkNGVmNmY3NWYx@thread.v2/1717145937454?context=%7B%22contextType%22%3A%22chat%22%7D

Bundle Condition : freetxt code Patient : age gender Observation1 : age Observation2 : Gender Servicerequest : Code

(patient OR Obs1&2) (info : patient needed for other requests)

2. Careplan status : active activity.reference(task.inputvalue.questionnaireorfocus.questionnaire) imbeded

3. Bundle Condition : code

4. Careplan status : active activity.reference(task.inputvalue.questionnaireorfocus.questionnaire) imbeded

5. Bundle QuestionnaireResponse

6. Careplan Activity.Reference(Requests) (1..*) imbeded + extensions

[bdc-ehealth]

@costateixeira @LionelCremer @NathanPeeters @JDW2021 @NISN-SMALS

The examples for this proposal are available on this branch: https://build.fhir.org/ig/hl7-be/pss/branches/issue-41/index.html

They validate against the validator and IG publisher. I eagerly await remarks about the conformance to the R4 text, but I am for the moment not aware of any.

Some minor proposals from my side: the extra data from the PSS system are now relatively untyped (strings, integers,...). They could be replaced by codes (e.g. SNOMED-CT codes) to make the content more language independent. That will also prevent the use of different languages in the exchanged data. The translation could be the official one from the terminology server at that moment, managed by the FPS Health (NRC).

[LionelCremer]

@bdc-ehealth , @costateixeira , Based on the examples provided, I don't see the advantages of using PlanDefinition. The content does not seem to be used or to offer any useful information for either the backend or the frontend.

@bdc-ehealth , Wouldn't it be better to add extensions for the score, radiation level, etc., directly in the ServiceRequest/MedicationRequest, instead of in the BackboneElement of the activity array of the CarePlan resource?

@bdc-ehealth , In the antimicrobial workflow, patient variables such as gender and birthdate are not needed. Consequently, the EPD will not provide this information. Does this mean that all resources (Conditions, MedicationRequest, CarePlan, ...) will refer to a Patient resource that either doesn't exist or is empty?

[LionelCremer]

Here is a visual representation of the requests and the responses comparison between the 2 proposals:

[costateixeira]

Operations can be defined on three levels: the level of the system, de level of the resource and the level of the instance. I understood José's proposal to be one or more custom operations (OperationDefinitions) on the level of an instance of the resource Plandefinition, named "Radiology" or "Antimicrobial". The input would always be a Bundle, and the result a Careplan. The contents of the bundle and the Careplan are according to the needs of the project i.e. to be determined.

The proposal was exactly NOT to use custom operations if the PlanDefinition $apply operation would cover these cases.

[costateixeira]

The diagram is very useful - looking at the diagram I would immediately choose for the standard option, which is more robust than a custom operation. If the idea is that a custom operation is more relatable to our current scope, why bother with FHIR and not make a custom JSON? The use of PlanDefinition is the approach defined by the FHIR community - description and examples here: https://build.fhir.org/ig/hl7-be/pss/branches/cpg-guidance/functional-overview.html