[XL] Implementing metadata in the lenses

[aalonsolopez]

Good morning everyone! @amedranogil @joofio @jkiddo @riccardo-leoni-dw

Yesterday I forgot to write this down here, but I will mention some considerations about this task: In my opinion, and having in mind a solution to this, this will be more a breaking change than I originally thought. As is intended to storage the lenses in a FHIR Server, we must change Focusing Manager to consume the lenses from this, instead of our lens-selector.mvp2. This will make this service to be more like a resources repository (like this which is used by our fhir-connector to upload all the resources to our servers) than a normal service. So the solution I thought was:

1. Make a tool that makes the transformation of our lenses from its actual .js file format to the FHIR format and FSH file everytime we want to commit changes to one of our lenses, or creating new ones, etc... So we actually develop JS files but these are transformed into FSH or FHIR JSON.
2. Once the lenses are in FSH format, we will upload to the actual repo a folder with the lenses in FSH format, and we will develop a new FHIR-Connector (or integrate with the existent one) to upload the lenses to our FHIR servers.

So, I think thats pretty much everything that I had to say. If someone need further explanations about this, don't hesitate on asking me!

[amedranogil]

In my vision there are 2 options:

1. creating a CI/CD script, so that developers do not have to update the final Lens form, this should be done automatically.
2. having the FHIR-connector create the lenses and push them to the server, i.e. no need to store the raw FHIR lens in git.

I would like to think of the Lens in FHIR format as the "compiled" form of the lens. The source for any lens should be a Partial FSH file (to fill in the metadata for the lens), and a .js file with the code (which will be enbeded into the FSH when "compiling"). If I understood correctly the tool you propose already does this (BTW, please upload the tool as independent repo to github).

The FHIR-Connector for Lenses would be the best option IMO, as it would just ingest the git repo source and process it to push it to the FHIR server, as all connectors are supposed to do (connect to source, adaptit, provide the FHIR content). Also there is no possibility to miss steps on compiling the lenses, plus there is no need to store the compiled lens.

[jkiddo]

I'd say its bold to assume that all lenses can and should be written in js. It may be the case that many are in js, but you cannot assume all lenses will be .

[joofio]

so let me try to explain my point and clear some confusion.

1. lenses do not need to be a fhir server. What is intended is that passing information about lenses complies with the specification.
2. this is about metadata and so we need to understand in which moments (methods of the API if you prefer) this is going to be used.
3. Jens is right about the format of lens, they could virtually be coded in any language.

With this, i propose we clear 2 things. When this format should be employed. I am thinking about expanding this part of the epi GET https://fosps.gravitatehealth.eu/focusing/lensesbut I think this could be used in the focusing as well. for example in response to this POST https://fosps.gravitatehealth.eu/focusing/focus/bundlepackageleaflet-2d49ae46735143c1323423b7aea24165?preprocessors=preprocessing-service-manual&lenses=lens-selector-mvp2_pregnancy&patientIdentifier=alicia-1add another resource that are the lenses.

This does not need to be that complicated :)

[amedranogil]

we already discussed the code of the lenses, we agreed that, yes, eventhough there can be lenses in other languajes, for the prototype this will be JavaScript.

We have still to agree exactly how will other languajes be noted, there needs a way to let the system know which interpreter to use to execute the lens.

[amedranogil]

it is not complicated, it is just agreein in the details.

The hole point is as @joofio said, that there is a common interpretation of the lenses. Eventhough the lenses do not require a FHIR server, maybe for storing locally a FHIR server which already performs compliance with the IG is a nice solution (maybe not the most optimal one).

Please read @aalonsolopez and my comments as a technical discussion on how to reach the goal of managing lenses with the IG specification, and not a discussion of the specification it self. We mostly discussed DevOps ensuring coding and deployment of the lenses is streamlined, these are details outside the specification of the IG.

[joofio]

as for the lenses, i dont think they should be only one language but i dont have a strong opinion on that.

for the rest, I would keep everything the same, and add another layer (a function if you will) for the groups of API calls i have mentioned that provide the content in json under the specification of the lenses.

Probably this is too difficult for me to explain through text and examples might be easier. feel free to schedule a meeting.

[amedranogil]

its bold to assume that all lenses can and should be written in js

I had in my notes "Arden syntax could be integrated into new Lens specification" Arden syntax is an HL7 standard, https://doi.org/10.1016%2Fj.jbi.2012.02.001 .

There where also the FHIR rules we once discussed could be used.

Anyway the lens code is written in, it should be specified which languaje is used to select the correct interpreter.

[joofio]

agree with language.

Can we meet for discussing this? I think its better than writting at this moment.

[joofio]

Discussion of Lenses (9.2.2024)

/focusing/lenses to return searchset (Bundle) of lenses (Library)

We need to add the class (or ID) of the lenses that does something.

We need to include the lenses in the focused ePI

To this highlight, we need to explain what lens did that. - related to class (or id, or wtv)

TODO: João to create example of focused lens and searchset.

UPM: to develop the new focusing and list of lenses.

[aalonsolopez]

To focus on that parts, what are the fields that @riccardo-leoni-dw needs for the frontend? @joofio

[joofio]

@aalonsolopez done right?