[ DRAFT ] HL7 FIHR Patient CRUD, basic version #2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Michael H. Siemaszko <mhs@into.software>
Signed-off-by: Michael H. Siemaszko <mhs@into.software>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problems
HL7 FIHR model related
Type-specific XSD schemas (e.g. 'patient.xsd') are not self-contained, reference all other types, and all reside under one namespace – it makes no difference whether EMF model is generated from such type-specific XSD schema ('patient.xsd') or main schema containing all types;
EMF Ecore generated off such XSD schema contains close to 1400 eClassifier definitions (EClasses, Enums, EDataTypes);
Java code generated off such EMF Ecore reaches beyond limits of Java language – exceeding the 65535 bytes limit for initializers and methods as well as 65536 entries constant pool limit, i.e.:
“The code for the static initializer is exceeding the 65535 bytes limit” (see
org.hl7.fhir.JurisdictionValueSetEnuminorg.avatar.fhir.model.corebundle);“The code of method doSwitch(int, EObject) is exceeding the 65535 bytes limit” (see
org.hl7.fhir.util.FhirSwitch.doSwitch(int, EObject)inorg.avatar.fhir.model.corebundle);“The code of method createPackageContents() is exceeding the 65535 bytes limit” (see
org.hl7.fhir.impl.FhirPackageImpl.createPackageContents()inorg.avatar.fhir.model.corebundle);“The code of method initializePackageContents() is exceeding the 65535 bytes limit” (see
org.hl7.fhir.impl.FhirPackageImpl.initializePackageContents()inorg.avatar.fhir.model.corebundle);“Too many constants, the constant pool for FhirPackageImpl would exceed 65536 entries” (see
org.hl7.fhir.impl.FhirPackageImplinorg.avatar.fhir.model.corebundle);‘Patient’ EClass does not extend EObject directly – is part of 4-level deep class hierarchy;
‘Patient’ EClass does not define any attribute which can be used as ID – only in one of the types it inherits from such is declared, but not as attribute but as reference to specialized EClass called 'ID'; this results in "The given EObject of EClass Patient doesn't contain a id attribute but should have one" error when attempting to save such to Mongo database;
EMF related
loadInitialization=”true”) results in code which does not work – results in “java.lang.RuntimeException: Missing serialized package: xhtml.ecore” error; this is perhaps related to wrong path to ECORE package defined inpackageFilenameof*PackageImpl(i.e. without/model/prefix); if “Load Initialization” did work, there would be fewer errors related to Java language limits and all these could be handled on EMF code generator side by splitting large methods into sub-routines / initializing static fields via static methods;XMLNamespaceEMF Generator Model, referenced from XHTML schema, cannot be read fromorg.eclipse.emf.ecoreJAR file, which required duplicating it in workspace asorg.avatar.fhir.model.namespace; however, this in return resulted in a different error related to namespace clash and required temporarily redefining itsnsURIto "http://www.w3.org/XML/2024/namespace", untilXMLNamespaceEMF genmodel contained inorg.eclipse.emf.ecoreJAR can be referenced directly;HAPI FHIR (Java API for HL7 FHIR Clients and Servers) related
"HAPI FHIR – Java API for HL7 FHIR Clients and Servers" cannot be used with tech stack required to use for AVATAR Libraries project:
org.hl7.fhir.instance.model.api.IbaseResource;Gecko related
REST API methods do not return responses in XML format
Currently, all REST API methods defined on
org.avatar.fhir.rest.PatientResourcereturn responses in JSON format, despite being annotated as producing XML media type, and specifyingapplication/xmlrequest header;EMFRepository does not support storing EObjects of EClasses which do not define ID attribute directly
org.hl7.fhir_patient.Patient) does not define any attribute which can be used as ID – only in one of the types in inherits from such is declared, but not as attribute but as reference to specialized EClass called 'ID';AbstractEMFMongoRepositoryexpects ID attribute directly on EClass of EObject being saved – it does not take into consideration attributes of references defined on types inherited from, i.e.valueattribute oforg.hl7.fhir_patient.Idreference defined onorg.hl7.fhir.Resource, from whichorg.hl7.fhir.Patientinherits;EPushStreamProvider does not support creating push streams off EClasses which are part of a complex class hierarchy
Currently, it appears
EPushStreamProviderdoes not support creating push streams off EClasses which are part of a complex class hierarchy and do not extend EObject directly, as ClassCastException is thrown during index initialization when using EPushStreamProvider with such EClass (org.hl7.fhir_patient.Patient);EMF validation of payloads passed to REST API methods does not work in JakartaRS
Currently, for all REST API methods containing message body (POST and PUT), defined on
org.avatar.fhir.rest.PatientResource, content validation does not work in JakartaRS – same exact configuration worked with JaxRS;Solutions
HL7 FIHR model related
Modify FHIR Ecore generated off XSD schema in the following way:
ResourceContainer– it is through this reference that most of the other 1400 eClassifiers (EClasses, Enums, EDataTypes) are pulled in to thePatient;This exact solution was applied in
org.avatar.fhir.model.patientbundle, while full FIHR Ecore along with problems described is present inorg.avatar.fhir.model.corebundle.EMF related
org.avatar.fhir.model.namespacebundle holdingXMLNamespacemodel, and modify itsnsURIto "http://www.w3.org/XML/2024/namespace", untilXMLNamespaceEMF genmodel contained inorg.eclipse.emf.ecoreJAR can be referenced directly;Gecko related
fakeIdattribute directly onorg.hl7.fhir.PatientEClass and mark it as ID – apparently, this alters the model itself and duplicates information already present, and should only be used temporarily until underlying issue of EMFRepository lack of support for storing EObjects of EClasses which do not define ID attribute directly is addressed;Temporarily skip using
EPushStreamProviderand query Mongo database directly to initialize index – this solution is present inorg.avatar.fhir.service.patient.impl.PatientIndexServiceImpl.initializeIndex()method, while theEPushStreamProviderproblem can be observed inorg.avatar.fhir.service.patient.impl.PatientIndexServiceImpl.initializeIndex_EPushStreamProvider()method;Temporarily disable EMF validation for all REST API methods containing message body (POST and PUT), defined on
org.avatar.fhir.rest.PatientResource;Questions
I. What does 'patient file' refer to?
II.
Which version of HL7 FHIR specification should be supported – only latest one (R5) or previous versions as well and if so, which?
Can it be expected that servers from which health providers will connect to this system will support latest version (R5)?
III. Should "Capability Statement" be implemented?
Based on https://www.hl7.org/fhir/capabilitystatement.html and https://www.hl7.org/fhir/profiling.html#api, apparently it is required in order for such solution to be compliant with HL7 FHIR standard;
IV. Should security (authentication / authorization) be implemented? eg. via Keycloak?
Based on https://www.hl7.org/fhir/security.html#6.1.0, it seems it is required in order for such solution to be compliant with HL7 FHIR standard;
V. Should REST API endpoint methods defined on
org.avatar.fhir.rest.PatientResourcebe fully compliant with HL7 FHIR standard or such basic implementation is enough?Based on https://www.hl7.org/fhir/http.html, it seems exact implementation of these CRUD methods as per this spec is required for such solution to be compliant with HL7 FHIR standard;
VI. Should record versioning be supported?
Based on https://www.hl7.org/fhir/overview-dev.html and https://www.hl7.org/fhir/resource.html, record version is one of the required elements of resource (including 'Patient' resource) and is used for tracking changes to resources, and preventing changes overwriting each other;
VII. Beyond annotating REST API methods as producing XML media type, and specifying
application/xmlrequest header, is there some additional requirement for responses returned to use XML format?Currently, all REST API methods defined on
org.avatar.fhir.rest.PatientResourcereturn responses in JSON format, ignoringapplication/xmlrequest header;VIII. Does Gecko EMF Mongo repository (
org.gecko.emf.repository.EMFRepository) support storing EObjects of EClasses which do not define ID attribute directly?org.hl7.fhir_patient.Patient) does not define any attribute which can be used as ID – only in one of the types it inherits from such is declared, but not as attribute but as reference to specialized EClass called 'ID';AbstractEMFMongoRepositoryexpects ID attribute directly on EClass of EObject being saved – it does not take into consideration attributes of references defined on types inherited from, i.e.valueattribute oforg.hl7.fhir_patient.Idreference defined onorg.hl7.fhir.Resource, from whichorg.hl7.fhir.Patientinherits;fakeIdattribute directly onorg.hl7.fhir.PatientEClass and mark it as ID, but this alters the model itself and duplicates information already present.IX. Does Gecko EMF Push Stream Provider (
EPushStreamProvider) support creating push streams off EClasses which are part of a complex class hierarchy and do not extend EObject directly?Currently, it appears it is not supported, as ClassCastException is thrown during index initialization when using EPushStreamProvider with EClass which is part of a complex class hierarchy and does not extend EObject directly (
org.hl7.fhir_patient.Patient)X. Does EMF validation of payloads passed to REST API methods work in JakartaRS?
Currently, for all REST API methods containing message body (POST and PUT), defined on
org.avatar.fhir.rest.PatientResource, content validation does not work in JakartaRS – same exact configuration worked with JaxRS;XI. Should EMF-repository based version of
#toEObjectmethod be included inorg.gecko.search.util.DocumentUtil, instead of being duplicated across projects?org.gecko.search.util.DocumentUtil.toEObjectmethod expects ENTIRE EMF EObject to be stored in the Lucene index, which is completely unrealistic – in any type of commercial / production application such approach quickly results in Lucene index becoming unusable, both for searching and opening;#toEObjectmethod implementation is using such approach. However, such is NOT YET available inorg.gecko.search.util.DocumentUtil, therefore it must be duplicated, for example in:org.avatar.fhir.service.patient.impl.PatientSearchServiceImpl.toEObject(Document, EMFRepository);XII. Can
org.gecko.search.util.DocumentUtil.ECLASS_URIbe made public, instead of being duplicated across projects whenECLASS_URIhas to be stored during index creation?E.g. duplicated again as
org.avatar.fhir.service.patient.impl.PatientIndexHelper.FIELD__ECLASS_URI, previously in PlayerTour project, and each time approach of storing in Lucene index only fields searched on is used (see question regarding#toEObjectmethod for more details);XIII. Considering Java language limits triggered by full HL7 FIHR model when using static Ecore approach, should dynamic Ecore approach be used instead?
XIV. Considering all these issues and time needed to fix those, should a fully compliant backend using "HAPI FHIR – Java API for HL7 FHIR Clients and Servers" (https://github.com/hapifhir/hapi-fhir) be set up then?