UNDER DEVELOPMENT

Scenario

There are two simple, openEHR based EHR-systems (system A and B).

System A is used by a general practitioner. It is just possible to record a patient's blood pressure. Therefore, records in system A consist of a composition 'encounter' which documents a patient's blood pressure by using the 'blood pressure' archetype.

System B is used in a hospital with both in-patients and out-patients. As in system A there is also a composition 'encounter' which documents a patient's blood pressure by using the 'Blood Pressure' archetype (mainly used for the outpatients). Furthermore, there is a composition 'vital signs' which also documents a patient's blood pressure by using the 'blood pressure' archetype (mainly used for the inpatients).

Now, imagine the following story: A patient (let's call him Paul) sees his GP a few times. Each time the GP, who uses system A, records Paul's blood pressure and documents it in Paul's EHR (system A).

Questions and Answers

Question: What are the general steps to exchange data between two openEHR systems?Answer:

Question: Every time the GP documents information about Paul's blood pressure, an appropriate 'contribution' is added to Paul's EHR. Correct?
Answer: Yes.

Question: Does that mean that every time a new version of the composition 'encounter' (containing the current blood pressure) is added to Paul's EHR?
Answer: Yes (either a new composition within a 'versioned composition' or just a new composition).

Question: If the GP's EHR-system should get the new feature to generate and display a list of the patient's saved blood pressure measurements, how would that be realized?
Answer:

The system could generate such a list by reading the particular values from the saved versions of the composition 'encounter' (using a combination of version locator and path to access the single data elements).
Maybe smarter: The values could be retrieved using the 'archetype query language'.

Question: When generating this list, it would be nice to display not only the measured blood pressure values but also the date of the measurements. Could that be picked from the 'event context' of the particular composition-version? Or should be the 'history'/'event' structure used generally?
Answer: Preferably the date documented within the observation 'history'/'event' structure . (The date in the 'event context' of the particular composition-version and the 'history'/'event'-structure of the observation might differ.)

Question: And if such a list has to be created based on an archetype which is not an observation archetype and thus, does not contain a 'history'/'event' structure (for instance an evaluation archetype)?
Answer: (...I suppose, in that case, the event context had to be used...)

One day Paul's GP admits him to the hospital as an inpatient. Concurrently the GP transmits Paul's EHR data to the hospital.

Question: How would that be done technically? Does System A send a text file containing the necessary information structured in dADL or a derived XML-format to system B?
Answer: Technically this is done in a transport protocol agreed by the two communicating systems. It can be XML or dADL.

Question: How would Paul be identified in the transmitted data file?
Answer: According to the EHR_EXTRACT http://www.openehr.org/releases/1.0.2/architecture/rm/ehr_extract_im.pdf

Question: Is there an example for a file like that available somewhere to get an practical insight how it works?
Answer: see above.

Question: In the exchanged file the used archetypes are listed but not defined. Does that mean that the receiving system is able to correctly interpret the received data only if it has access to the same archetypes the sending system has used when creating the file?
Answer: Yes, especially in case of decision support systems. (A pure reporting of the received data might be possible without having access to the used archetypes.)

Question: Back to our example: System B receives blood pressure measurements from system A. In system B there are two possibilities to store (and display) blood pressure measurements (either within the 'encounter' composition or within the 'vital signs' composition). How does system B decide where to store and display the received data?
Answer:

The received data should be represented as is. That is the data should be presented using the blood pressue archetype. For read-only purpose, the data will not be saved in the receiving system. But if for any reason, the data have to be saved, it should probably be saved in a special composition, e.g. recevied EHR_EXTRACT composition to indicate that the data were not originated from the current system.

Question: It might be easy in the example as the structure of the EHR of system B is similar to the structure of system A - but what about openEHR based EHR systems with a completely different structure?
Answer:

In the hospital Paul's blood pressure was measured regularly and entered in a screen form based on the 'vital signs' composition. Furthermore, Paul's blood pressure was measured when he arrived at the hospital and entered in a screen form based on the 'encounter' composition. After Paul had been discharged the data documented during his stay in hospital were transferred to his GP. Now the GP's EHR system (system A) has to deal with the issue that it receives a set of blood pressure measurements from system B entered in different compositions/contexts.

Question: How will system A manage that (e.g. the composition 'vital signs' might not be available in system A)? (Would be all blood pressure measurements mapped to the existing structure in system A? Would system A be able to create a list of ALL blood pressure measurements created during the hospitalization?)
Answer:

In any openEHR system, if one particular archetype isn't avialable for interpreting the exchanged data, some basic way of presenting the data using the semantics from the openEHR Reference Model should be used. The RM is the structure of any openEHR-based EHR system.

Question: If system A will be able to receive all blood pressure measurements created during the hospitalization correctly, would it later be (within system A) possible to distinguish those measurements which were initially saved using the 'vital signs' composition and those using the 'encounter' composition?
Answer:

The id of the template that is used to create the data will be preseved in the RM instances when data are saved. However it is not required to have the original composition (most likely a template) to interpret the data semantics correctly. A well modelled archetype can be safely reusable across different clinical context.