Technical Interoperability

From NCPeH CY
Revision as of 12:38, 7 June 2021 by Mneoph (talk | contribs) (Removed protection from "Technical Interoperability")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Technical Domain

O. 10 Do you have an overall description of the National Infrastructure systems that enable the cross-border exchange of health data?

Response

Yes. For more information please refer to:

  • Annex TE 1 NCPeH CY Technical deliverable – Part A, Sections A2 and A3

T. 16 [NCPeH-B] Are the applications providing access to cross-border health data available in controlled environments (such as Authorised points of care, Trusted Third parties)?

Response

Yes. Inside the Government Network the authentication and authorization are via NCP Active Directory.

  • 2 Way SSL for Private Sector HCP plus

8 Ariadne Government Authentication Gateway (citizens are identified in person in Citizen Service Center)

  • NCP Active Directory

For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Sections A2 and A3.a

T. 1 Does the NCPeH provide a technical communication gateway (SW) for CBeHIS connected to the National Infrastructure?

Response

Yes. National Gateway (OpenNCP A) is deployed in separate Isolated Virtual Machine which is connected directly to the DB Cluster, Medico and Audit/Monitoring Services (supports Patient Search, PS Search, eP search, eD submit and Consent Services). For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Sections A2, A3.a.v, A3.a.vi, A3.b and A4.f.ix

Additionally, Gnomon API (OpenNCP B) is Providing XCPD, XCA List, XCA queries and PS/eD to HTM transformation services. For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Sections A4.e, A4.f.iv and A4.f.x

T. 11 – T. 14 Is your NCPeH Technical Gateway connected to the National Infrastructure including Identity Providers?

Response

Yes. OpenNCP A Authentication and Authorization Country B + 2 Way SSL that OpenNCP supports. For more info please refer to Annex TE 1 NCP CY Technical deliverable – Part A, Sections A4.f.vi and A4.f.ix OPENNCP B Services via GNOMON API wrapper Public Sector NCP Active Directory Inside the Government Network 2 Way SSL for Private Sector HCP plus Ariadne Government Authentication Gateway (citizens are identified in person in Citizen Service Center) PanCyprian Medical Association Registry (for medical Doctor Validation) Pharmaceutical Services Pharmacy Registry (for pharmacist validation) For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Sections A3.a.1, A3.a.2, A3.a.iv.1, A4.a.i, A4.a.ii. and A5.a
  • Annex OP 2 Operation and Organizational Structure Section 3

T. 12 How does the NCPeH ensure that the National Connector connected to the NCP Technical Gateway: is developed and operates in a managed and secure way; and ensures secure exchange of cross-border data? =

Response

NCPeH CY is developed and operates according to development standards and operation policies which they align with IT Security Standard – Web Application Security Standard of European Commission C(2018) 7283. For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Sections A3.a, A3b, A4.a, A4.e, A4.f.iv,
  • Annex TE 1 NCP CY Technical deliverable – Part B. B11. IT security Standard and Web Applications
  • Annex OP 2 Operation and Organizational Structure 3

T. 2 Please describe how the Technical Communication Gateway solution fullfils the Functional and Non-Functional Requirements and implements technical bindings?

Response

Please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Section A6

T.2-1 [T.8; T.9; T.10] Is the NCPeH technical communication gateway implemented and operated in a manner to exchange necessary data (such as publish and query configuration information) with the Central Configuration Server?

Response

NCPeH technical communication gateway it able to publish configuration information into the Central Configuration Server.

  • Annex TE 1 NCP CY Technical deliverable – Part A, Section A4.f.iv

OpenNCP Gateway which is responsible to publish the configuration information of the services to the eHDSI SMP Server. There is also a component embedded in client connector software which triggers the SMP Server making queries to it, in case a configuration of another country needs to be retrieved.

  • Annex TE 1 NCP CY Technical deliverable – Part A, Appendix AV.a

T. 17 [NCPeH-B] Does the NCPeH ensure that the end users' applications implement the eHDSI and national policies (i.e. patient identity traits, patient information notice, production partners, user authentication)

Response

Yes.

  • As a provided core component, the Default Policy Manager has been included into the NCP-A side (WS Server build).
  • Implementation of the Policy Manager Interface (Assertion Validator)
  • Validation of the Cross-Enterprise Privacy & Authorization (Oasis standard XSPA)
  • Validation of the XCPD, XCA and XDR attributes (subject, role, permission...)
  • Conformant with HL7 RBAC rules (role-based access control)

FR01 HP Identification and authentication:

• NCP Active Directory – Annex TE 1 NCP CY Technical deliverable – Part A, Sections A3.a.iv.1, A4.a.i and A4.a.ii • Public Sector Doctors – Annex OP 2 Operation and Organizational Structure, Section 4.2 and Annex TE 1 NCP CY Technical deliverable – Part A, Section A5.a.i • Private Sector Doctors – Annex OP 2 Operation and Organizational Structure Section 11 and Annex TE 1 NCP CY Technical deliverable – Part A, Section A5.a.ii.2 • Private Sector Pharmacists –Annex OP 2 Operation and Organizational Structure, Section 12 and Annex TE 1 NCP CY Technical deliverable – Part A, Section A5.a.ii.3 • 2-way SSL – Annex TE 1 NCP CY Technical deliverable – Part A, Sections A3.a.ii and A5.a.ii.1 for CY HPs • NCP-A side – Annex TE 1 NCP CY Technical deliverable – Part A, Section A4.f.iv

FR03 Patient identification:

• Medico HIS identification (Based on Civil Registry Identification) – Annex TE 1 NCP CY Technical deliverable – Part A, Section A3.a.viii.1

GDPR:

• Annex OP 5 NCPeH DPIA • Annex OP 8 NCPeH CY Patient Consent and PIN

T. 18 [NCPeH-A ePrescription] Are the NCPeH and National Infrastructure able to process eDispensations coming from other NCPeH-B?

Response

Yes. For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Section A4.e.i.4

T. 19 [NCPeH-A] Is your NCPeH technical gateway able to provide the Clinical Documents (e.g. Patient Summary or ePrescription) required by the cross-border services which your NCPeH plans to deploy?

Response

Yes. PS XML L3 and PDF L1 document examples:

  • Annex TE 2 Reference Test Documents – Part A, Sections A1.1 and A1.2

eP XML L3 and PDF L1 document examples:

  • Annex TE 2 Reference Test Documents – Part A, Sections A1.3 and A1.4

T. 20 [NCPeH-A] How is the clinical information gathered into the documents:

Response

From Central Database Cluster. The clinical information is created from the database based on data enter until then.

  • The PS A eP A CDA Server requires a patient ID and the corresponding date of birth in JSON form.
  • This information is provided from a country B through the OpenNCP portal.
  • Then, a mechanism is triggered on the PS A, eP A CDA Server, which is responsible to search the exact combination of the given patient’s ID and date of birth in the SQL database cluster.
  • If the patient’ ID is found in the database, then the employed mechanism retrieves all the appropriate patient’s data and constructs the CDA documents in XML and PDF form.
  • Annex TE 1 NCP CY Technical deliverable – Part A, Section A4.f.ix

T. 3 Do you have a written description of distinct environments (i.e. development, training, pre-Production, Production)?

Response

Yes, we have two distinct environments.

  • Testing environment (single server)
  • Production environment (HA environment)

For more info please refer to:

  • Annex TE 1 NCP CY Technical deliverable – Part A, Section A2.

End of Technical Domain