Create native JSON composition format from OPT

Implementation Platform
21

Hi Giovanni,

do you use the master branch? Could you please try the latest develop branch and check if the error still occurs?

Cheers,

Birger

22

@surfer am pretty sure Ethercis does export in ‘RAW’ JSON - just use format=RAW as a parameter and change Content-type to application/json.

I can’t test so apols if I got that wrong

23

I can confirm what Ian mentioned about generating RAW compositions from Ethercis. However I have not yet tried to commit it to EHRBase.

regards

1 Like
24

This is what I get in Ethercis if I put ‘format’:‘RAW’ in parameters, regardless of the Content-type chosen:

htp://127.0.0.1:8080/rest/v1/composition/d5745655-f131-4856-a72d-6537d5c005a9::ethercis.crs4::1?format=RAW
500

Error 500 #1.0.0 Invocation exception to method:retrieve:java.lang.IllegalArgumentException: Invalid element detected in map

HTTP ERROR 500

Problem accessing /rest/v1/composition/d5745655-f131-4856-a72d-6537d5c005a9::ethercis.crs4::1. Reason: 

    #1.0.0 Invocation exception to method:retrieve:java.lang.IllegalArgumentException: Invalid element detected in map
Powered by Jetty:// 9.4.z-SNAPSHOT

The same composition with ‘format’:‘ECISFLAT’:

htp://127.0.0.1:8080/rest/v1/composition/d5745655-f131-4856-a72d-6537d5c005a9::ethercis.crs4::1?format=ECISFLAT
200
{
“composition” : {
“/composer|name” : “Physician”,
“/content[openEHR-EHR-ACTION.procedure-sus.v1]/description[at0001]/items[at0002]|value” : “SUS::0408060140|FASCIECTOMIA|”,
“/content[openEHR-EHR-ACTION.procedure-sus.v1]/ism_transition/careflow_step|value” : “local::at0043|Completed|”,
“/content[openEHR-EHR-ACTION.procedure-sus.v1]/ism_transition/current_state|value” : “openehr::532|completed|”,
“/content[openEHR-EHR-ACTION.procedure-sus.v1]/time|value” : “2018-12-11T11:20:07,230”,
“/content[openEHR-EHR-ADMIN_ENTRY.admission.v1]/data[at0001]/items[at0013]|value” : “local::at0020|Eletiva|”,
“/content[openEHR-EHR-ADMIN_ENTRY.admission.v1]/data[at0001]/items[at0041]|value” : “CirĂșrgico”,
“/content[openEHR-EHR-ADMIN_ENTRY.admission.v1]/data[at0001]/items[at0071]|value” : “2010-09-01T00:00:00-03:00”,
“/content[openEHR-EHR-ADMIN_ENTRY.admission.v1]/data[at0001]/items[at0073]/items[at0084]/items[at0087]|value” : “IBGE::MT|MATO GROSSO|”,
“/content[openEHR-EHR-ADMIN_ENTRY.admission.v1]/data[at0001]/items[at0073]/items[at0104]/items[at0106]|value” : “CGC_HOSP::029f40596e8f365e39a10337202fcde4|4dc5277c8fb69ad41181cad1844491e6d2eb7999ae9f638a|”,
“/content[openEHR-EHR-ADMIN_ENTRY.hospitalization_authorization.v1]/data[at0001]/items[at0016]|value” : “0”,
“/content[openEHR-EHR-ADMIN_ENTRY.hospitalization_authorization.v1]/data[at0001]/items[at0061]|value” : “2010-09-01T00:00:00-03:00”,
“/content[openEHR-EHR-ADMIN_ENTRY.patient_discharge.v1]/data[at0001]/items[at0002]|value” : “2010-09-01T00:00:00-03:00”,
“/content[openEHR-EHR-ADMIN_ENTRY.patient_discharge.v1]/data[at0001]/items[at0047]|value” : “MOTSAIPE::12|Alta - melhorado|”,
“/content[openEHR-EHR-ADMIN_ENTRY.patient_discharge.v1]/data[at0001]/items[at0048]|value” : “false”,
“/content[openEHR-EHR-EVALUATION.problem_diagnosis-sus.v1]/data[at0001]/items[at0002.1]|value” : “CID10::M720|M72.0 Fibromatose de fascia palmar|”,
“/context/setting” : “openehr::232|secondary medical care|”,
“/context/start_time” : “2018-12-11T11:20:07.227+01:00”,
“/language” : “en”,
“/territory” : “BR”
},
“meta” : {
“href” : “rest/v1/composition?uid=d5745655-f131-4856-a72d-6537d5c005a9::ethercis.crs4::1”
},
“format” : “ECISFLAT”,
“templateId” : “hospitalization_ocean”

@Dileep_V_S how did you do it?

25

Can you upload the .opt as well @surfer? I will try and test it later today.

I would suggest you use the xml for now - I played with Better and ehrBase CDRs last night and got xml moving between the two with only as minor tweak to add the openehr schema to the namespace. THe raw json formats were somewhat different, which is not a surprise as this is still very early in adoption/ conformance testing.

26

Thanks Ian,
Here they are (composition and template):

27

Yes. I’m using the master branch. The zip 0.10.0 official alpha release https://github.com/ehrbase/ehrbase/archive/v0.10.0.tar.gz
When I try with the develop branch I get this error:
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project test-data: Fatal error compiling: invalid flag: --release -> [Help 1]
I’m trying to investigate the cause


28

The latest version on the dev branch requires Java 11. Maybe this is the issue.

29

Thanks, It’s definitely something I have to correct

30

Built up the develop branch version successfully.
I tried the composition and template posted but I receive the same error:
500
{“error”:“Unable to create an instance of com.nedap.archie.rm.support.identification.UIDBasedId”,“status”:“Internal Server Error”}

Any idea of what’s going wrong?

31

Hi Giovanni,

the first issue I found is regarding the namespaces in XML. The file should look like this:

<composition
	xmlns="http://schemas.openehr.org/v1"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" archetype_node_id="openEHR-EHR-COMPOSITION.hospitalisation.v1">
	<name>
		<value>Hospitalisation</value>
	</name>
	<archetype_details>
		<archetype_id>
			<value>openEHR-EHR-COMPOSITION.hospitalisation.v1</value>
		</archetype_id>
		<template_id>
			<value>hospitalization_ocean</value>
		</template_id>
		<rm_version>1.0.2</rm_version>
	</archetype_details>
	<language>
		<terminology_id>
			<value>ISO_639-1</value>
		</terminology_id>
		<code_string>en</code_string>
	</language>
	<territory>
		<terminology_id>
			<value>ISO_3166-1</value>
		</terminology_id>
		<code_string>BR</code_string>
	</territory>

However, there seem to be more issues regarding the validation of DV_CODED_TEXT. We will take a closer look what’s going on. I will hopefully have some news next week.

One issue I was able to resolve was this one:

			<items archetype_node_id="at0013" xsi:type="ELEMENT">
				<name>
					<value>Admission type</value>
				</name>
				<value xsi:type="DV_CODED_TEXT">
					<value>Eletiva</value>
					<defining_code>
						<terminology_id>
							<value>local</value>
						</terminology_id>
						<code_string>at0020</code_string>
					</defining_code>
				</value>
			</items>

as the language was set to “en”, I had to replace “Eletiva” with “Elective”.

32

Hi Birger,

That XML namespace issue is one I have known about - I think it is down to the slightly different behaviours of the serialization libs used by Better and ehrBase (or more likely somebody told me that!!).

The issue about codedText validation of the text value as well as the code_string is interesting - it might be worth raising this with other implementers and @thomas.beale. I can see some arguments that validating on the text is not required or helpful. There are going to be some interesting issues in this area around SNOMED CT synoynms.

33

thanks @birger.haarbrandt . looking forward to see the file cleaned.

@ian.mcnicoll What I can tell, in my little experience, is that starting from the ORBDA db I had to make corrections, both in Template and Compositions, to use Better and Ethercis that aren’t overlapping. In general Better is more “forgiving” and needs less corrections. And now Ehrbase is again different from the other two in terms of adjustments needed.

34

At least the namespace handling is something that we could certainly fix by doing some internal pre-processing. However, I cannot say when this will be ready and for now this needs to be done client-side.

35

It is something to consider as part of conformance testing before you ‘fix’ it - it is possible that it is Better who are doing things slightly differently. Or does this matter, at all in conformance terms. The Better approach makes sense, in their terms, where the element is not the root element - the openEHR ns is on the root which is a simple wrapper.

These are just the small (hopefully!!) niggles that confomance testing will bring up and that we need clarify.

36

I think from an XML perspective, the use of namespaces in the example given by @surfer looks appropriate. I think it still is canonical XML. Hence, I think EHRbase should accept the compositions.

Birger

37

digging into this a little further, I suspect it should not be an issue. It is I think an artefact of the Ehrscape GET /composition that wraps the composition in a metadata header (which carries the openEHR ns) . From what I can see the REST API mandates that the composition is the root element and therefore should carry the ns there. I’ll test ASAP.

38

Ah now I see I am talking nonsense!!

This not the lack of an openEHR namespace on the root but the fact that it is not expressed as a ‘default’ namespace. I agree @birger.haarbrandt the format that @surfer sent over should be acceptable, as should the current ehrBase approach (digging back into my creaky knowledge of XML namespaces ).

39

I believe you’ve figured it all out now (did not check, but your last post makes sense), I’d just like to point out that Better EHR (and consequently Ehrscape) has 2 REST APIs; the legacy proprietary one, and the slightly different openEHR one.

40

Yep - just doing a little tidyup of a single Postman collection that will handle both, so we can start to compare and contrast.