I have a detailed understanding of openEHR’s Integration Model, and learned Generic_entry. And I have tried to convert and integrate some standard data sets of China’s health industry standards with openEHR standards. These are some of the Generic_entry I have generated so far, sorry for the Chinese version only. openEHR-EHR-GENERIC_ENTRY.laboratory_examination_.v0.adl (73.1 KB) openEHR-EHR-GENERIC_ENTRY.clinical_auxiliary_examination.v0.adl (29.2 KB) openEHR-EHR-GENERIC_ENTRY.physical_examination.v0.adl (131.8 KB) openEHR-EHR-GENERIC_ENTRY.complaints_and_symptoms.v0.adl (66.9 KB) openEHR-EHR-GENERIC_ENTRY.other_inspections.v0.adl (6.8 KB)
I have some confusion about the follow-up technical route and the usefulness of these Generic_entry.
1.I am not very clear about the “archetype-driven data converter” and “mapping tool” in the technical route,Is it a direct mapping between Generic_entry and care_entry?
2.At present, I am directly mapping the Chinese national standard with openEHR, which may result in multiple Generic_entries for the same concept. For example, the liver cancer standard data set and the lung cancer standard data set will have the concept of basic patient information, so there will be two Generic_entry, and the data items of these two prototypes are not exactly the same,how should I solve this problem, should I merge the content or do other solutions.
3.In the follow-up, in addition to the relevant standards of China, I also consider using the Integration Model to realize the integration of standards such as FHIR and CDA. What are your opinions on these?
Interesting topic and I’m eager to learn more about your work.
To completely understand your perspective/use-case, I want to point you to the following quote and question:
The result of this step is data that are expressed in the openEHR type system (i.e. as instances of the openEHR reference model), and are immediately amenable to processing with normal openEHR software.
Do you utilize the results of the first integration step in “normal openEHR software”? If not, it might make sense to skip it. This would save you modeling and processing work.
On the other hand, if you have systems available capable of working with generic integrated openEHR data (i.e. data converter) then it might make sense though.
I worked on integrating different standards/formats, like IHE XDS and FHIR, with openEHR and never made this extra step over imported generic entries so far.
GENERIC_ENTRY is different from the parent and abstract ENTRY class. It is part of the integration package and it is designed to represent legacy data and other data integration scenarios.
GENERIC_ENTRY should be seen as an intermediate representation for external data. It is not guaranteed that you can transform all existing external data into openEHR structures. In that case, the GENERIC_ENTRY allows you to, at least, include all that data into a unique openEHR EHR system. The “archetype-driven data converter” and “mapping tool” could exist to convert that data into pure clinical ENTRY classes, but that’s something to be done explicitly for each case, since having generic and automatic conversion rules can be nearly impossible.
Probably the best approach is to keep those GENERIC_ENTRY separated, so you can keep the track to the original data structures. If you are going to do the effort of harmonizing them, then maybe it would be worth to directly try to harmonize your data to the clinical ENTRYs and archetypes.
There are people working in mapping or aligning openEHR archetypes and FHIR resources, but it is difficult to have a one-to-one mapping. It is even more difficult for CDA, since you will need to define your own transformation rules according to your CDA structure. Some useful work is for example this XDS archetype from the Apperta CKM, that helps to represent the CDA header: Clinical Knowledge Manager
Hi Zhao, this is a broad topic with many ways of doing integrations.
From experience, after trying several ways, what works best IMHO is to model a template representing the object you want to integrate with an openEHR CDR, following the model of the other standard or format. Because in general you already have HL7 v2.x or CDA or FHIR or DICOM in place, and the new thing is the openEHR CDR, so you must respect what is already there.
Then map using models, not instances, that is: map the openEHR template items to the CDA implementation guide or with the corresponding FHIR profile.
Finally implement those mappings in some technology. I prefer to use an integration engine like Mirth Connect to everything that has to do with transforming different data formats and using different communication protocols (e.g. MLLP for HL7 v2.x, HTTP or SOAP for CDA, HTTP for FHIR, DICOM TCP or Web for DICOM, etc).
Another point: it’s nearly impossible to create a generic integration, every try I saw for that just failed, there are too many custom things on data integration, so I prefer doing this ad-hoc, case by case.
Hi Jake, and thank you very much for your reply.
My current work is the conversion and mapping between some Chinese national standard datasets and openEHR.For example, here is a Chinese group standard,Standard Data Specification for Hepatobiliary Diseases: Standard Datasets of Medical Records for Liver Cancer Scientific Research(Sorry, the file is only available in Chinese). TCMDA 003-2020 肝胆疾病标准数据规范：肝癌科研病历标准数据集.pdf (689.1 KB)
I parse the file and map it with openEHR to generate Generic_entry,and this process is automatically generated by the software system.In the adl file of generic_entry generated here, the relevant information of the standard data set and specific data items are in the box identification. openEHR-EHR-GENERIC_ENTRY.history_of_present_illness.v0.adl (18.1 KB)
Currently my work is carried out on the HMC HMC platform,the corresponding integrated modules are still being perfected and developed, and there will be corresponding function updates in the new version of HMC in the near future.
