The current REST specifications does not seem to support creation of compositions by passing an id (similar to creating ehr with id). Is there any plans to support this feature?
This will be useful in situations when migrating data from one CDR to the other. Creating new compositions ids can have implications as the id may be referenced within and outside the CDR and will all need to be updated.
regards
I think this is a case for the IMPORTED_VERSION class (Common Information Model) which I donāt think is well supported by the current API, at least there are no clear use cases for it.
Though I donāt have strong opinions, I think this use cases shouldnāt be part of the normal clinical flows API, but of an administrative API, because the use case is importing documents from another CDR, which is an administrative task, not directly related with the health care process.
Technically you can post a custom composition ID within the body of the POST, see: EHR API
But it depends on the implementation on how it is processed and if it is actually persisted. There was some discussion about that topic some time ago and whether or not it should be more streamlined. Simply put, either if this possibility should be removed from the REST spec or if it should be made mandatory option for implementers IIRC. Does anyone happen to know where we discussed that?
We could discuss about relaxing conditions for PUT (now used to āupdateā only) so that you can also create a first version and store it under that id, ā¦ but that id should be the same as the one in composition.uid.
@Dileep_V_S , is that not possible for you to place/set the id in the composition and then just use POST?
If you would need the use-case described by Pablo, you could use the ehrās contribution-post, or perhaps you could propose to support POST/PUT on versioned_composition - as far as I remember we did not had that use-case yet.
EHRBase seems to ignore this and create a new id.
+1. The specs should remove the ambiguity for implementors. I personally feel that we should allow this either in POST or PUT.
Can you you elaborate a bit on what is the ambiguity that you think should be removed?
It will be good if we do that as it improved flexibility for deployments to evolve and refactor content as they mature and grow.
However, we may need to consider some possible situations and cover for it. Do we allow versioned composition IDs? if yes how do we allow newer versions to be committed without the older ones? How do we ensure system integrity in that case(openEHR systems are supposed to maintain versions) as he target CDR will not have the older versions?
Where can I do that?
The POST composition example body contains this
"uid": {
"_type": "OBJECT_VERSION_ID",
"value": "8849182c-82ad-4088-a07f-48ead4180515::openEHRSys.example.com::1"
},
That would imply that you can pass versioned composition ID in POST. But the description does not make it clear whether it will create a new composition or create one with the ID passed.
Also, if the passed version ID is used, then can that be any version or should it be only version 1?
Indeed
Yes, that might need better clarifications. But the principle is that if possible, the server will create a (first version of the) composition with the ID passed, or respond with a status error in case of ID-conflict (this is however not yet specified, but I guess would be 409) or other kind of exception (invalid content, invalid ehr_id, etc).
We did not discussed in SEC about use-case when the first version is not that with id=1, but I donāt see any impediment there: by default, the first version is 1, but i guess you may choose to start with another higher number, as long as youāll the build a lineage in version history. Some refs: Common IM - local_versioning, base_types identification_of_versions and base_types version_tree_id_class.
If you have a JIRA account you can do it in the SPECPR and use āITS - Rest APIsā component please - see https://specifications.openehr.org/releases/ITS-REST/open_issues
This is what I meant we have discussed. And I actually found the ticket now:
https://openehr.atlassian.net/browse/SPECITS-62
So this topic is indeed not clarified and thereās no specified behavior yet.
@jake.smolka you are right, and @Dileep_V_S issue is closely related to this issue. But in my impression we donāt have an agreement yet on the solution for that ticket, still in the investigating phase. So more feedback/thoughts are welcome.
Hi all,
We are currently working on a project which involves the export and import of compositions from CDRs.
I have made the necessary changes to ehrBase to allow us to do this. Weāve had a few issues but overall it seems to be working ok. @ian.mcnicoll we need to move this discussion on, as the ehrBase team are waiting on changes to the standard before they make code changes.
Finally, I am confused as to why importing/exporting doesnāt happen at the contribution level, however there doesnāt appear to be away to simply retrieve all the contributions for an ehrId, am I missing something ?
Do we know what specifically they are waiting on?
Do you mean EHR Extract import / export?
That would be easy for any implementation to do, but Iām interested to know why just obtaining Composition Versions is not sufficient.
We would implement the solution which would check if the submitted composition has an uid set.
This also would work for flat āinternational_patient_summary/_uidā: āc5db0694-5cd2-4fd1-a5bf-ed25f1c5d371::ehrbase.org::1ā.
This makes the most sense and donāt require a change in the API.
Iād be happy with that. I think it is clear enough.
Is anyone pushing hard for PUT /composition? I donāt understand why this is more Restful since we are not updating an existing composition, in either of the use cases described.
[quote=āthomas.beale, post:14, topic:2113ā]
Do we know what specifically they are waiting on?
Decision on how to create a new composition but with a provided uid.
Yes but its just not supported in the REST API.
Why are composition version not enough? Good question which we discussed internally .
The context is bulk transfer of contents of one CDR to another, preferably using standard REST API calls
Templates are easy
EHR is easy
Need a way to retain composition UIds so that internal references and links donāt have to be recreated/ hooked up (so the need for the composition call that supports inected composition UID on create)
Maybe it is just a case of reading and cloning each composition version in the new CDR but we felt that we should try to retain the contribution wrapper particularly where there might be eg an addition, a modification and delete, all in the same contribution, so that the rollback capacity would not be lost.
If we do recreate the contributions, Iām still a little hazy on the need to retain any internalIds, even the contributionId itself- are these ever referenced i.e what would happen if we just regenerated new uids (other than for compositions) ? or do we need a way to clone a contribution retaining existing Ids?
Maybe we should move the Contribution / export-import discussion to a new topic? I t would certainly be very col to demonstrate how this works in terms of vendor/tech neutrality of CDRs
Yes, well I did have some reasons of my own, this is the main one. So what you really want to do is rewind a series of full commits done to an EHR inside one CDR onto an EHR in the other.
You definitely want this.
What I would suggest is that the contents of each Contribution in the source system be worked out, and then the commit contribution call be used in the target system to apply that set of versions as a new Contribution. Itās risky to assume that exactly the same commit structures will work in a target CDR, unless itās exactly the same software, and no local config differences could modify it (even something dumb like locale-specific markers).
Also, you need to be careful on commit times in the target system. If you donāt call a commit function, but instead try to paste the data representing the Contribution straight in, the commit times will actually be wrong on everything, since these commits are being done ānowā, not when they were done in the original system.
In this case, the Contributions will get new UIDs, but the Compositions can retain what they have.
I am talking here of single EHR kind of transfers. If you are talking about essentially copying the entire contents of a CDR to another (say, a more recent version of the same product, whose installation should be invisible to users) then a low-level direct copy will potentially make sense.
I wrestled with that idea but I discounted it because if I add it as a parameter on an API I am explicitly stating that I want to preserve the composition Id, if you just consume it from the composition itself then its easier to do it accidentally. I guess itāll need lots of documentingā¦
