Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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: 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:

  1. 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).
  2. 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? (System A sends a text file containing the necessary information structured in dADL or a derived XML-format to system B?)
Answer:

Question: How would Paul be identified in the transmitted data file?
Answer:

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

Question: In the exchanged dADL 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 dADL 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:

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:

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:

  • No labels