Sam Heard wrote:
Gerard Freriks wrote:
Hi,
Reading an HL7 list.
To me it seems there is exchange of the same data for two reasons.
1- an order, an instruction, an advice, a professional opinion, a letter, a lab result, itself, etc
2- the documentation of , the provision of information about, the order, the instruction, the advise, the opinion,the letter, the lab result, etc.
Eg: the prescription on paper handed to the patient, the prescription electronically that is sent and serves as a kind of trigger event to make acts happen at the receiver side.
And the documentation of acts in a system about the real world.
What they have noticed is one of the fundamental criticisms on the RIM by the philosophical ontologists.
In CEN it is simple we deal only with the EHR and considers the EHR a documentation device that deals with reason two only: documentation of what has happened.
A lab test that is sent to an EHR system as data (information about the patient) is received and stored in the in-tray of the system.
The physician reads the data and accepts it to the healthcare record at that moment he documents the reception of the lab results and make them part of the EHR. Then he is able to formulate a comment about them or act up on them. The comments or the actions will be documented again in the EHR.
In CEN we deal with the EHRextract for exchange only. The extract is an abstract of that what has been documented.
Question: Is data that is not yet documented part of the extract?
If so. How is that indicated?
If not what should we do?
I think it should not, because the EHR is there to document what has happened in the view of the healthcare provider.
Orders, instruction, letters them selves are outside of the scope of the EHR.
I don’t agree. I think that while this is what most extracts will be about, this is not in principle true. The Extract is capable of sending any piece of an EHR. The requested piece (e.g. ‘everything to do with a cystic fibrosis patient’s care for the last 2 years’) could easily have Observations, Evaluations (i.e. any kind of opinions, including diagnoses, risk analyses, plans, goals etc), Instructions (and a CF patient will have a lot of those), and Acts (records of actions taken due to Instructions). THere is no reason not to be able to transport this kind of information in the Extract.
The openEHR (and CEN) approach is simple. The information contains the “triggers”; you send the information to the right person/place and it gets acted on. Just like writing a letter: you put a stamp and address on the front, and you drop it in teh post box. You don’t have to ring up the post office to ask them to send the letter; they already know what to do. If you write in that letter to your aunt that you would like some dried flowers from her garden to give to your daughter on her birthday, your aunt knows what to do, once she has read the letter, and barring difficulties, she does it. If she fails, she writes back and tells you she cannot. If she has fallen down teh stairs and is in hospital, someone from there or your family will ring you.
Personally I do not believe the obsession with “trigger events” is meaningful in health information. “Triggers” are part of protocol design; protocols are for sending information, and should be kept separate from the requests/replies of the information. So, like the post office example, the protocol of how mail is sent around the world is a ‘post-office protocol’ which you, the letter writer know nothing about. You just know about the request you made to your aunt, and her reply.
I think that next to the EHR extract we need something that indicates that it is not an extract of what is documented but something that is an order, instruction, advice, a letter, a lab result, that is data to the receiver until he documents the reception and accepts it to his record system.
I prefer a new construct that carries the notion that it is a trigger.
In an openEHR environment, the receiver and sender systems will both understand the order, since it will be based on an appropriate, shared archetype of an Instruction (e.g. an order for a drug), and it will be at the “prescribed” step (prior to the “dispensing” step). What is not in the Instruction is the information that some particular pharmacy X is being asked to dispense the drug. But consider what normally happens: a patient presents a printed prescrption to the pharmacist and recieves a package in return. In e-health, the pharmacy receives a request for a drug; the request itself does not need to indicate which pharmacy is to dispense the drug; only the envelope in which the request is carried (like the postal example above). In other words, the pharmacy processes all requests for drugs (assuming apporpriate details included in the message) directed to it, rather than some other pharmacy.
How does this get done? Consider the following possibilities:
- the pharmacy acts like a provider, and is able to see the patient EHR. In this case, all the data required for dispensing will be in the Instruction in patient B’s record. The trigger for actually dispensing will be a notification from the physician’s sytem to the pharmacy system asking for Instruction 0494585 to be acted upon.
- the pharmacy is just a service, and not privy to health records of patients. It therefore has no reason or capability to receive or view pieces of an EHR. In this case it needs to be sent message which acts as a notification, and carries the content. Such a message can be constructed from the relevant Instruction.
Now, in the second case, the easiest solution in principle is to generate a copy of the appropriate part of the Instruction, and send it off to the pharmacy by some communication servce, such as a call to their webservice.
In a messaging environment, one might assume an HL7 or EDI message. Generating an appropriate HL7v2 message would not be hard. But for v3, the situation may be more problematic: v3 RMIMs contain predefined models of much clinical content (replicating clinical models and information models of EHR content), mixed in with the schema representing the message; it may or may not be easy to generate the appropriate message, since there are many attributes which are required, which are not present in the EHR. How this can be solved will remain to be seen.
Since the content of this new construct will be the same information as an EHR-extract I foresee an envelope for the EHR indicating that it is an extract of a document and an envelope indicating that it is a trigger.
This is the solution-in-principle above; it still requires sensible service models for both sender and receiver; these service models encapsulate the protocols for sending and receiving, acknowledgement and all such things.
The signature placed on the extract of the document indicates: I sign this and take responsibility for the content of the extract.
The signature placed on the trigger indicates: I order you, I instruct you to do something and I take responsibility for that order, instruction.