DocumentReference and KMEHR

[fdetaver]

I have several issues with the current BeDocumentReference profile as we believe this resource will be used for KMEHR documents at some point :

1. How should we map the different KMEHR codesystems into BeDocumentReference ? Shouldn't we provide a mapping or guidance ? Should we allow KMEHR code systems in the relevant fields ?
2. The 2 mandatory codes (CD-TRANSACTION & CD-HCPARTY(dept)) in KMEHR are used to determine access (access matrix). What about the cardinality of those concept in the resource ? What to do for access if we don't know the document type in relation to the access matrix
3. Isn't there a need to deal with the encryption layer related to KMEHR documents exchange ? The attachment in binary could be encrypted (use of provenance ?)

[fdetaver]

Hello,

I apologize for not being present yesterday (17/04). In my defense, I had a double booking with another eHealth meeting ...
Marcelo has warned me that an input was needed or the issue will be closed without answer.

This issue is still important to me and other systems. As such, I would rather not close it completly.
However, we agreed that this issue can be put "on pause" or transfer to another queue or whatever and the profile discuss here would be restricted to the use of a specific project.

We believe that, if this profile is put out there for a more general usage, these questions are still relevant for the compatibility with the current KMEHR system.

Best regards,
Félix

[fdetaver]

This is an example of a KMEHR transaction (dieticianreport) in a getTransactionList :

<transaction> <cd S="CD-TRANSACTION" SV="1.0">contactreport</cd> <cd S="LOCAL" SV="1.0" SL="PatientAccess" DN="" L="fr">yes</cd> <cd S="LOCAL" SV="1.0" SL="PatientAccessDate" DN="" L="fr">11/04/2024 16:06:22</cd> <date>2024-04-11</date> <time>16:06:22.0000000+02:00</time> <author> <hcparty> <id S="ID-HCPARTY" SV="1.0" SL="">HUB ID</id> <cd S="CD-HCPARTY" SV="1.1" SL="" DN="" L="fr">hub</cd> <name>RSB</name> </hcparty> <hcparty> <cd S="CD-HCPARTY" SV="1.0" SL="">deptdietetics</cd> <name/> </hcparty> <hcparty> <id S="ID-HCPARTY" SV="1.0">HCP INAMI</id> <cd S="CD-HCPARTY" SV="1.0" SL="" DN="" L="">persdietician</cd> </hcparty> </author> <iscomplete>true</iscomplete> <isvalidated>true</isvalidated> <recorddatetime>2024-04-11T16:06:22.537</recorddatetime> </transaction>

I removed some of the fields that are irrelevant or for identification

[bdc-ehealth]

@fdetaver proposes to check whether there exists a valueset (in some codingsystem: LOINC/SNOMED-CT/HL7-CDA e.g. ) for all CD-Transaction codes that can contain a PDF. We will contact Stephane Houpresse (workgroup metadata) about this.

For the hospital department as an author, we propose to use the practiceSetting.

[bdc-ehealth]

WG: Vitalink will check whether it is possible to have multiple authors.

[bdc-ehealth]

@fdetaver mentions that PatientAccess(Date) could be relevant for the security discussions in the Infrastructure and Security WG.

[bdc-ehealth]

Business question: recordtimedate: date will be the date the documentreference was created (this is the date the document was shared in the system), and attachment.creation will be the date when the businesscontent of the document was created.

Who is the business here???

[dtemans]

WG: Vitalink will check whether it is possible to have multiple authors.

I agree with this.
Concerning the BeDocumentReference profile, I recommend returning to a 1..N cardinality with regard to the author, this would respect the hierarchy of the information producing ecosystem. For example, this would make it possible to indicate the producing site, the service/department and the natural person who created the information concerned. In addition, all of the internationally used Fhir development libraries are based on the Fhir R5-6beta specifications respecting a 1..N cardinality of the author, this poses a problem in the canonical representation of Json/Xml because depending on this cardinality, the author is represented by a reference table and not a single reference in the case of the BeDocumentReference profile. I would also like to point out that the production of information and its forensic validation should not be confused. Indeed, we may very well have an author who does not have the right to assume medico-legal responsibility for the publication of information. For example, a specialist candidate (PG) may be the author of information but the forensic responsibility for publication depends on his supervisor, who must then be represented by the authenticator element of the DocumentReference resource. The use of the practiceSetting element specifies the clinical context of the document concerned; semantically, the notion of author and clinical context are very different. Finally, it would be functionally simpler to find all the information concerning the author in the same place in the Fhir resource materializing a document, this would greatly simplify computer processing and make it possible to develop effective functional constraints.