[RMM] Content manager

[joofio]

steps:

1. gather examples of RMM
2. fhir spec
3. create server
4. create frontend

[gmej]

We can use https://min.io as Object storage

[gmej]

The SM Manager will have 3 types of documents:

1. Public documents. Only metadata is stored for these files, as they contains the url to the resource (public available resource outside FOSPS).
2. Controlled access documents. This material will only be available to a set of users. This document can't beaccessed without proper authentication and authorization in the request. These documents will make use of a Minio storage.
3. Embedded documents. These documents are base64 encoded inside the ePI

This service will have 3 main operations available:

1. CRUD metadata.
2. CRUD files.
3. Match making. This is a query with query parameters like langauge, terminiologies, etc. The SM Manager will return a Bundle with all the matches for that query.

[gmej]

Implementation order:

1. CRUD metadata
2. CRUD files.
3. Match making

[gmej]

@10alejospain feel free to split this issue in as many issues as you want, and reference them here.

[gmej]

Additional Support Material Profile: https://build.fhir.org/ig/hl7-eu/gravitate-health/StructureDefinition-ASM.html

[10alejospain]

@joofio About the content for testing the Supporting Material Manager I will ask you to provide:

• Material example that contains the category resource related to one of the ePI that we're usually using (even if it's example data without meaningfull info)
• More detailed example or exaplanation on the Document reference 3 example to be able to understand that flow correctly.

[joofio]

https://www.medicines.org.uk/emc/rmm-directory/E

something like this would be helpful?

passed the question to other WPs

Alejo Esteban @.***> escreveu (terça, 12/03/2024 à(s) 15:03):

@joofio https://github.com/joofio About the content for testing the Supporting Material Manager I will ask you to provide:

• Material example that contains the category https://hl7.org/fhir/R5/documentreference-definitions.html#DocumentReference.category resource related to one of the ePI that we're usually using (even if it's example data without meaningfull info)
• More detailed example or exaplanation on the Document reference 3 https://build.fhir.org/ig/hl7-eu/gravitate-health/DocumentReference-asm-3.html example to be able to understand that flow correctly.

— Reply to this email directly, view it on GitHub https://github.com/Gravitate-Health/supporting-material-manager/issues/3, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMJVUAL6NOEHFDRN5E772DYX4KNPAVCNFSM6AAAAAA7663NIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJRHA3DINRWHE . You are receiving this because you were mentioned.Message ID: @.***>

[10alejospain]

I need the Category resource on the examples related to one of the ePI that we already have. I don't know if we have any RMM related with any of the ePI but it would be usefull if any partner could provide something like that so we can test the matchmaking of the ePI + RMM.

[amedranogil]

To facilitate this discussion, I'll paste some documentation we have prepared:

The categorization of the aRMM/SM is the one reflected in the metadata (see the FHIR Profile) of the most interesting material for the G-lens system. Some key parameters are the following:

• Type: specifies if the material is a document, infographic, image, video, or even other type of media such as an application (this could help introduce specific technological solutions to the appropriate population segments easily through G-lens). It is assumed that the material is digital content, but material could also be services and/or products.

• Language: specifies which language is necessary to understand the material, this is useful to present only material in the language that the patient understands furthering the personalization. For the proof-of-concept the cultural differences may not be considered, particularly for language-less materials; these materials could be icons or videos where there is not text or speech, and thus could potentially be interpreted without any language, however iconography, gestures, and other non-verbal communication is still subject to culture and may not be as effective when considering a global community.

• Associated product: a direct link to the product, if applicable as there could be aRMM/SM which is generated for health conditions and not just for specific products. This could help the system identify the most appropriate ePI and link to it.

• Category: specifies which standard terms apply to the material. This could include conditions such as pregnancy for aRMM/SM specifically intended for pregnant people; it could also include other diagnostic and process terms, conforming a keyword-type indexing for the material for which the union of terms summarizes the addressed population. In future iterations of the FOSPS, application of Natural language Processing techniques over textual type materials could automatically propose an initial selection of categories for the HCP to validate.

The SMM could use the information present in IPS to matchmake available materials to the patient. This feature ensures that materials that are not associated with a particular medicinal product can still be delivered to patients who may need them.

The set of materials offered to the patient contains the materials which are registered with one of the languages the patient understands or has no language (i.e. it employs non-verbal media); and where the codes in the category of the aRMM/SM metadata is a subset of the codes found in the IPS collecting all terms mentioned in all of the sections of the composition (i.e. as part of the Allegires, Intolerances, Problem list, immunizations, history of procedures, medical devices, or other sections).

Additional considerations could be added, for example excluding material developed in a modality that the patient is incapacitated to consume (e.g., excluding audios and verbal videos for hearing-impaired patients).

The matchmaking process for ePIs is very similar to the matchmaking process for IPS, in the sense that both language and term/categories considerations apply. On one hand, the language of the ePI needs to match the language of the material (e.g., if verbal, non-verbal always complies). On the other hand, the terms of the aRMM/SM metadata need to be a subset of the categories found in the preprocessed ePI annotations, or other ePI codified terms.

SM which has a targeted product, should be only be available to patients who have been prescribed the product (or a specific product which is with in thte class of products specified in the SM metadata) or to the ePI for the specific product. Which means that SM meant for a specific product, should always match the ePI, and should only match an IPS if the patient is prescribed the product AND the SM categories are a subset of the IPS terms. Which means that an SM may be excluded for particular patients, for example SM for a target product, which is meant specifically for pregnant people, then would be excluded for patients who are not pregnant.

[amedranogil]

• More detailed example or exaplanation on the Document reference 3 example to be able to understand that flow correctly.

There are 3 methods of SM storage:

1. Remote Content: When a content is publicly available on the Internet (e.g. in a web server).
2. Controlled Content (the URL pointing to FOSPS host) When content is hosted by the FOSPS, so that it may be access controlled. This is also useful when the content is in the professional stakeholder’s private filesystem and needs to be shared.
3. Inline Content In FHIR this property can be used to attach In-line representation of the document. This can be used instead of Controlled content (or even remote content) in specific cases like the usage of the Content Trust Framework (CTF).

So take that example as one of the 2 class, instead of being a JSON+FHIR type, set it up as a PDF (for example); in any case it should be hosted relative to the platform deployment. This storage type should also be authorised (i.e it is only accessible with a valid token bearer).

[amedranogil]

I need the Category resource on the examples related to one of the ePI that we already have. I don't know if we have any RMM related with any of the ePI but it would be usefull if any partner could provide something like that so we can test the matchmaking of the ePI + RMM.

To keep it simple, i would propose examples for the Alicia IPS:

1. SM with 1 or 2 "matching" codes
2. SM with 1 matching, and antother not matching Alicia's conditions (i.e des not match)
3. SM targetting a prescribed medicine for Alicia, and other matching category (e.g. the condition)
4. SM targetting a prescribed medicine for Alicia, and other non-matching category (simulating SM for a medicine which is used for multiple diseases, this case would be for another disease that Alicia is not suffering)

[joofio]

I dont think that exists yet, but i can create, even if only with mock information just for matchmaking purposes.

[gmej]

Remember that this task must take into account client-side focusing

[amedranogil]

no so much client-side focusing, but that there needs to be a client-side operation (the matchmaking) that avoids sending the IPS to the server

[joofio]

@joofio to create it still. For Alicia

[joofio]

@10alejospain do you have the link for the backend?

[10alejospain]

I don't have ot deployed yet. I could have it for next week.

[joofio]

So regarding this issue. We need to link the RMM to (at least) two things.

1. medication
2. disease

Do you agree? and the match would be by at least one of them.

[10alejospain]

It could be dissease, allergy, intollerance or any other condition available in the ePI to mach with the possible content of the RMM

[joofio]

Yes my idea of disease is something from the patient.

Then we make the match as:

1. the product and the condition for adding in the epi.
2. just the condition (or something from the patient) for browsing tailored content without being in the epi.

Makes sense?

[10alejospain]

Yes, I think so. @amedranogil do you agree?

[joofio]

something like this? https://build.fhir.org/ig/hl7-eu/gravitate-health/15-focusing-considerations.html (feel free to comment and/or edit)

[amedranogil]

This sounds like the epi+IPS matchmaking, this is described in D3.7 along with just ePI and just IPS match making. To the process there should also be languaje and accesibility conditions to apply.

We defined matchmaking using set theory, so basically it is intersection of "conditions" (as defined above: disease, intolerance, alergies, and any codeable concept inside the resource) of IPS, ePIs and ASM.

Here is the figure we used to present the concept during the review:

[joofio]

Done. New features and bugs on separate issues

[gmej]

I'm moving this issue to the corresponding repository in order to have a better organization.

[gmej]

Main functionality done in release v0.1.0

I'm creating the matchmaking in issue #4