Platform 

Designing a Healthcare platform can be more complex than individuals might initially think. Primarily this is due to the number of stakeholders involved. For example a platform may need to be designed by industry partners and used by citizens or healthcare organisations.  

There are four main pillars which need consideration in order to achieve interoperability across and between healthcare systems.  The four pillars are interconnected as featured in Figure 1 above and it is best to deal with each of the pillars concurrently. The four pillars provide the overall foundation for any healthcare platform. The four pillars are architecture, schema, terminology and protocol. The first pillar which is the base architecture needs to follow a selected meta model. For example a meta model such as one defined by IHE Profiles and which we have signposted on the research and platform sections of this sandpit. IHE profiles provide a common language (meta standard) for purchasers and vendors to discuss the integration requirements of healthcare systems and to support the integration capabilities of healthcare IT products. The IHE profiles also provide a clear implementation path for communication standards supported by industry partners and carefully documented, reviewed and tested iteratively over time.

The second pillar of the schema can provide a blueprint for the data structure. For example open schema within the system architecture can be aligned with the IHE profiles from the first pillar.  

The schema provides detail on agreed data structures about the kind of data to be captured, stored and details how the data identified for use are interconnected through defined relationships. For our demonstrator development we have followed the HL7 FHIRv4 schema to capture and store data as it is related mainly with clinical observation and monitoring of patients in different healthcare settings (See Practice Section Step 3 in CSDM Demonstrator). For alternative topics such as precision medicine or pharmacy or drugs related intervention it is better to follow i2b2 Schema instead. Or, alternatively if you want to conduct a cross-border cohort study using a particular aspect of a disease it is convenient to follow OMOP Schema. Generally it is useful to use open standards as the main instrument to achieve interoperability as this means that the  developer can have access to technical knowhow and detailed specifications which are published and freely available. Therefore ensuring that individual developers of the system align with the same data structure.

​

After finalising the schema based on your context or domain of application it is necessary to then choose the standard terminology so that the machine understands the same semantics meaning without any disambiguation. For our case we mainly use terminology from SNOMED-CT and ICNP. SNOMED-CT is a systematically organized machine processable collection of clinical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting. It is a most comprehensive and multilingual terminology used internationally. ICNP is more focused on nursing terminology to capture day to day nursing related observation for example ability to bathe, ability to walk etc. by realising importance of nursing terminology SNOMED international has entered a new agreement with  ICNP which will be published in SNOMED in September 2021 for the first  time.  

The final stage of the four pillars under development relates to the data sharing aspect of the healthcare system development. As we mentioned above, open standards are the backbone of healthcare interoperability now and in the future. For this reason we have to choose an Open Protocol for sharing information across platforms to support health and social care delivery. In our case study we followed open protocol to share and link data with other freely available data sets. For example we used SPARQL version 1.1 protocol to connect our data in CSDM platform with external UN geopolitical data; this is demonstrated in step 6 from the CSDM demonstrator under the Practice section. Additional reading that may be of interest used in the CSDM project is listed in the links below.