Pouvoir ouvrir un compte-rendu (documents pdf)

[nriss]

I think we have to investigate about having a fake ftp server to store images

Not sure we want to store images on HAPI What do you think @simonvadee @rodesousa ?

[simonvadee]

we already thought about it, we want to store documents (pdf, images, etc...) on minio which is an open source S3-compatible API (simple storage service). I think this issue is only a front-end issue for now, let's keep the backend for later ?

[nriss]

@simonvadee 👍 So, imagine there are multiple ways to find an image, the algorithm to request it should be on the front according to you ?

[simonvadee]

So, imagine there are multiple ways to find an image

this is a POC: there is a single way to retrieve an image (it's always a mistake to plan stuff for later "just in case").

the algorithm to request it should be on the front according to you ?

in an imaginary case, if there would be multiple ways to retrieve an image, we would try all the URLs until an image is returned.

[MiskoG]

I suggest we try the following approach @BPierrick

1. Just mock a single "Document" component for each patient, that will show an arbitrary publicly-available PDF. In this step we will be able to work on the frontend/UX aspects regardless of FHIR and document storage modelizations
2. [ need some FHIR research first ] Use a FHIR component that will modelize the presence of a document for a patient. When detected for a patient, still use a public arbitrary PDF file to show
3. [ need some tech research first ] Investigate how a S3 (minio) technology could help us to store the documents

[nriss]

So, imagine there are multiple ways to find an image

this is a POC: there is a single way to retrieve an image (it's always a mistake to plan stuff for later "just in case").

the algorithm to request it should be on the front according to you ?

in an imaginary case, if there would be multiple ways to retrieve an image, we would try all the URLs until an image is returned.

I just wanted to ask as a question, just to keep it in mind without implementing anything of course :)

[ need some FHIR research first ] Use a FHIR component that will modelize the presence of a document for a patient. When detected for a patient, still use a public arbitrary PDF file to show

The link to the pdf can be written in attachment.url for example see the documentation there -> http://hl7.org/fhir/datatypes.html#attachment

[BPierrick]

@nriss attachment type doesn't seem to be used enough in the displayed resources as shown :

Do you suggest an alternative? Using extensions or something else? 🤔

[MiskoG]

@nriss Great ! FYI we did something like this with @BPierrick : generate DocumentReference instances with these attributes

• subject
• content[0].attachment.url = an arbitrary public URL pointing to a PDF 😊
• description = "Compte-rendu d'hospitalisation" (@nriss is it the correct attribute according to you ? for storing a name that could speak to people, like "compte-rendu opératoire" or "lettre de liaison")

Next step is exploring how we can actually store those pdf files and link them with our FHIR instances !

[MiskoG]

An example on sandbox

"resourceType": "DocumentReference",
"id": "239c9e11-d915-57e9-bdd0-687ce9f98d35",
"meta": {
    "versionId": "1",
    "lastUpdated": "2021-12-08T17:49:44.266+00:00",
    "tag": [
        {
            "system": "http://terminology.arkhn.org/CodeSystem/source",
            "code": "ckuo369io000a0cp6ijgdpbtj"
        },
        {
            "system": "http://terminology.arkhn.org/CodeSystem/resource",
            "code": "ckwxtfn6d00000cqeko168qsu"
        }
    ]
},
"status": "current",
"subject": {
    "reference": "Patient/56fd22e2-bdfb-5a1c-ab0c-75fb8a37374a",
    "type": "Patient",
    "identifier": {
        "system": "http://terminology.arkhn.org/74ba75c5-ed35-4b44-a323-3d15a72aa32c",
        "value": "2"
    }
},
"date": "2017-02-09T00:00:00Z",
"description": "Compte-rendu d'hospitalisation",
"content": [
    {
        "attachment": {
            "url": "https://api.reseauprosante.fr/files/revues/file-648.pdf?id=20200717"
        }
    }
]

[nriss]

@nriss attachment type doesn't seem to be used enough in the displayed resources as shown :

I don't understand, why isn't it used enough ? The attachment datatype is used in DocumentReference.attachment

@MiskoG I see two options:

• DocumentReference.description attribute is defined as an Human-readable description of the source document.
• DocumentReference.attachment.title is defined as A label or set of text to display in place of the data.

The description attribute seems great for now, particularly if there is one attachment per DocumentReference :)

[nriss]

Next step is exploring how we can actually store those pdf files and link them with our FHIR instances !

Seems perfect! I created a repo for a timelinepatient ig! It will be used to show a documentation of all attributes used on the app. --> https://github.com/arkhn/arkhn-ig-timelinepatient

@BPierrick, can you create issue•s to write all the attributes you are displaying on timelinepatient ?