OpenNCP: PAC Service
21 Feb 13:30 14:30 CET
OpenNCP2.0 Development RoadMap
1º Sprint: 28Jan > 8 Fev (2 weeks) > Completed
2º Sprint: 11Fev > 22Fev (2 weeks) > WE ARE HERE
3º Sprint: 29Fev > 8Mar (2 weeks)
4º Sprint: 11Mar > 22Mar (2 weeks) (<- both weeks, or perhaps just the last week could be the code freeze?)
- Release date: 25March (Monday) > OpenNCP 2.0.0
-- Release Notes
Agenda
The goal is to analyse the hypotheses to implement PAC service: Patient Access
- Giorgio is requested to share the other relevant docs from KT1.4.10
Location
Skype (Licinio) + Netviewer
Participants:
- Arnaud Gaudinat
- Fredrik Dahlman
- Giorgio Cangioli
Konstantin Hyppönen- Kostas Karkaletsis
- Licínio Mano
- Marcello Melgara
- Marcelo Fonseca
- Milada Kovarova
- Norbert Répás
- Minde
Steen Manniche
MEETING NOTES
PAC Specifications & Implementation:
PAC service:
- [MarMel] Please Forget ePrescription (for OpenNCP 2.0.0)
-
A. Path: minimal effort / time but more constraints
- OpenNCP 2.0.0 > keep the NCP-a to NCP-b Flow
B. Path: more effort / time but more sustainable
- OpenNCP 2.2.0 > allow that only NCP-a is needed for PAC service
- ALTERNATIVE (Marcelo Fonseca): OpenNCP 2.2.0 > Add TM/TSAM as Portal dependency and use National Connector Library (Already implemented by PNs in OpenNCP) to connect to NI;
Non-epSOS country want to use
- Keep the 3 languages (Original, EpsosCDA, TargetLanguage)
TM
It takes as input epSOS Pivot as country B
++++++++++++++++++++
Assumptions - Example
Country B is Greece
Country A is Italy
Existing portalb workflow
Pharmacist accesses greek portal b
1. hcp asserion
2. identification service (finds an Italian patient)
3. TRC Assertion
3. patient service
4. Consent handling if needed
4. Retrieval of document (translation of document in country b language - greek in this occasion)
PAC Workflow
Italian Patient accesses Italian portal b
1. hcp asserion (needs to be specified new role and permissions for patient). I am not sure if patient is an HCP (healthcare point)
2. identification service (the system automaitically identifies itself, the patient stores to the portal the personal identifiers needed for matching with the patient)
3. TRC Assertion (the system automatically creates a trca with purpose of treatment, new role has to be defined)
3. patient service (the system automatically retrieves list of documents)
4. Retrieval and display of document (translation of document not needed, it's in italian language already, no transformation needed)
5. Consent handling must be part of ncp-a in order to allow patient to see its own data
6. QUESTION: does it needed a new audit event for this transaction?
So if the patient role had permissions on patient service he could probably see his documents
++++++++++++++++++++
As we've discussed only one possibility, for completeness I'm adding also other, maybe closer to Giorgio's proposal:
Currently, for epSOS1, TransformationManager(TM) provides following interface
- toEpsosPivot()
- takes epSOS friendly CDA and transcodes it into MVC codes with English designations returning epSOS pivot CDA
- used in NCP A
- translate()
- takes epSOS pivot CDA + target language and translates it (i.e. adds designations in target language) returning translated epSOS pivot CDA
- used in NCP B
For PAC, there are several possibilities how to use/adapt TM:
1. simulate NCP A + NCP B and call TM twice on the same document i.e. translate(toEpSOSPivot(epSOS friendly CDA), target language)
final coded element will contain designations in original language, English, target language
no changes necessary
2. into TM interface add new function doing both transcoding and translation used for PAC use case
final coded element will contain designations in original language, English, target language
no NCP-B is necessary
3. adapt TM function toEpsosPivot() to use target language by transcoding instead of default English
toEpsosPivot() would accept optional parameter target language and for each coded element it would search for designation in that language
final coded element will contain designations in original language, target language (without English)
no NCP-B is necessary
just one document parsing, i.e. faster CDA transformation
generic solution
For all possibilities, there is a crucial assumption that LTR contains designations in all required target languages.
NEXT Steps
- [To Do - OpenNCP Community] Re-start with PAC Implementation, using the original architecture design
- [To Do - Marcello+Giorgio] Clarify requirements and design guidelines for future versions of the PAC epSOS Servcie.