New wiki space

[Thomas Beale]

I have created a 'Terminology' space on the wiki. Initially I would like 
to get material from the recent IHTSDO meeting up there. The idea is to 
create very clear guidelines for archetype design, and to ensure the 
semantic congruence of archetypes and other aspects of openEHR with 
terminology. Remembering of course that openEHR is designed to work with 
any terminology, we will nevertheless be able to use a lot of the 
thinking coming from IHTSDO and SNOMED-CT.

See http://www.openehr.org/wiki/display/term/Terminology+and+openEHR

If anyone wants to add a 'key issue' I suggest you do it by modifying or 
commenting on the top-level page. Hopefully people from the terminology 
community, ontology community and also people from user organisations 
will help us collectively put some shape into this part of the wiki.

[note that for pure terminology-related discussions, of course the 
resources of IHTSDO and other organisations are of course more 
appropriate than here].

- thomas beale

Sending a new object using the Contribution

[Heath Frankel]

Hi Soheil,
An EHR repository requires a service interface which is yet to be defined by
openEHR.  Some of the classes such as EHR, Contribution and
VERSIONED_COMPOSITION are not classes used for containment purposes, they
are intended to be used as part of a service interface.  This is why the
draft ehr_extract_rm defines the classes EHR_EXTRACT, X_VERSIONED_OBJECT and
X_CONTRIBUTION separately.

The draft ehr_extract_rm define the X_CONTRIBUTION as part of the
SYNC_EXTRACT in Figure 11 (section 7), but the draft has some errors left
over from previous versions.  The MESSAGE_CONTENT parent type of
SYNC_EXTRACT I believe is equivalent to the EXTRACT_CONTENT parent type of
EHR_EXTRACT_CONTENT in Figure 7 (section 5), which is equivalent to
EXTRACT_ENTITY_CONTENT in Figure 6 (section 4).  Based on that premise, the
X_CONTRIBUTION is contained within EXTRACT_CHAPTER (see Figure 6), via the
content relationship to the SYNC_EXTRACT (subtype of
MESSAGE_CONTENT/EXTRACT_CONTENT/EXTRACT_ENTITY_CONTENT) that contains the
list of X_CONTRIBUTIONS and the EXTRACT_CHAPTER has an entity_identifier
which is the EHR ID providing an explicit relationship between the
CONTRIBIUTION and the EHR.

The Ocean Informatics EHR Server, provides a service interface that directly
operates against the EHR repository through the EHR and
VERSIONED_COMPOSITION classes rather than extract interface.  This EHR
Server service interface provides a CommitContribution method that has the
following parameters (among others):

* ehrId: HIER_OBJECT_ID
* audit: AUDIT_DETAILS
* versions: ORIGINAL_VERSIONT[]

You will notice that audit and versions are similar to those specified in
X_CONTRIBUTION, but the ehrId is an additional parameter to ensure the
versions are added to the correct EHR.  The Ocean EHR Server derives the
contribution UID from the contribution attribute in the versions.   

I believe that the development of the EHR Service interface is soon to
begin, but until then I hope this helps.

Regards

Heath

Product Development Manager
Ocean Informatics

 -Original Message-
 From: openehr-technical-bounces at openehr.org [mailto:openehr-technical-
 bounces at openehr.org] On Behalf Of Soheil Hassas Yeganeh
 Sent: Thursday, 15 October 2009 9:42 PM
 To: For openEHR technical discussions
 Subject: Sending a new object using the Contribution
 
 Dear All,
 
 According to the reference, common, and extract information models
 changes made to an EHR, including additions, should be sent through
 a contribution.
 There is no implicit or explicit link to an EHR neither in
 X_CONTRIBUTION nor in CONTRIBUTION.
 
 So, would you please let me know what is the scenario to send new
 objects (addition change type) using contribution or x_contribution
 classes?
 
 Bests,
 Soheil
 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical