Alternate EHR URI scheme


The current EHR URI scheme described in the architecture overview is something along the lines of

ehr://<ehr_id>@<system_id>/(<version_owner_id>[@version_time]|<version_uid>) /<content_path>

A more traditional resource locator format may be as follows:
Absolute URI ==> ehr://<system_id>/<ehr_id>[/( compositions | ehr_access | ehr_status | directory )'['(<version_owner_id>[@version_time]|<version_uid>']' /data/<content_path>]

Relative URI ==> ( compositions | ehr_access | ehr_status )'['(<version_owner_id>[@version_time]|<version_uid>']' /data/<content_path>]

This would also allow access to other parts of the EHR including version, ehrStatus, ehrAccess and directory




Heath Frankel
May 12, 2015, 8:27 AM

The main variation is the way that system-id is represented, rather than a made up syntax of @system_id I propose using the URI RFC defined approach of authority. Authority is optional as is in URLs but represents the concept of system better than @system_id. This would have no affect on the URIs you use in your LiU implementation as you don't specify system_id.
The other significant variation is treating the EHR class as the root of the URI rather than assuming the compositions collection and hence you are able to specify other EHR class attributes such as ehr_status and folder. Similarly, I am suggesting we state the VERSION attributes explicitly rather than assuming data. This means we can refer to audit_details etc.

Thomas Beale
May 12, 2015, 9:10 AM

@Erik - re: # fragments, of course you are right, I had forgotten that. They are browser side. Thanks for the ref - allowing non-AQL will be useful.

Sebastian Iancu
May 21, 2015, 4:13 PM

Some ideas based on experience at Code24:

We support composition|ehr_access|ehr_status|folder on the first part of the top level structure; also we support composition[vital_signs] for instance to indicate a composition based on vital_sign template.

The way we use (rarely though) the fragment is to indicate a function/method that should be called against the item that the uri refers to. For instance ..... content[openEHR-EHR-OBSERVATION.blood_pressure.v1]/data[at0001]/origin#year()

The way we use query is to indicate the episode: .... content[openEHR-EHR-OBSERVATION.body_temperature.v1]/data[at0002]/events[at0003]/data[at0001]/item[at0004]/value/magnitude?episode=E000123456

I'm ok with current style, I don't really need to move having to more explicit style porposed by Heath, but I'm not against it.
However if we do change it, i suggest to use composition (not compositions, -plural).

I'm still not sure if referring to current ehr we should do it without "ehr://" in the front. Can we better use ehr:/// for this purpose?

Heath Frankel
May 22, 2015, 12:10 AM

You say "not sure if referring to current ehr we should do it without "ehr://" in the front.". Not sure if you want it in front or not want it in front. My proposal above for current ehr is:

Relative URI ==> ( compositions | ehr_access | ehr_status )'['(<version_owner_id>[@version_time]|<version_uid>']' /data/<content_path>]

For example:

Regarding compositions vs composition, the idea is that we use the attribute names from the EHR RM class as we do for other classes in the XML schema.

Not sure where the proposal of "composition[vital_signs] for instance to indicate a composition based on vital_sign template" comes from, this is ambiguous with the object/version uids in this predicate.

I actually wonder if we should be going to a more traditional RESTful approach where we don't use the predicate style syntax such as:

Perhaps this deviates from the current path mechanism too much.

Thomas Beale
May 22, 2015, 8:25 AM

Q of EHR or system_id first - distributed EHR environment.

Agree - put into data types spec + link to REST & http URIs.

Register 'ehr' scheme.



Heath Frankel




Affects versions