Stream: implementers
Topic: GP contact report
Alexander Henket (Jan 23 2017 at 14:52):
When you visit a GP he usually does some structured reporting following the Subjective, Objective, Evaluation, Plan method. All 4 are principally text based, but S and E might be associated with a code (ICPC-1-NL for us), O might be replaced with Observations, and P might be e.g. a CarePlan, MedicationOrder or Procedure
S-O-E-P are grouped around a problem. If you come in with two problems (pain in ear and nasty cough) then two groups of S-O-E-P will exist associated to the same Encounter.
How does this play out in FHIR? It feels like we're missing an EncounterReport resource, and we could use Composition as fallback.
Lloyd McKenzie (Jan 23 2017 at 16:10):
I think the intention was that ClinicalImpression plus CarePlan was intended to cover this, but agree it could and should be better documented. You might want to raise a tracker item to specifically call out SOEP/SOAP in the documentation.
Lloyd McKenzie (Jan 23 2017 at 16:10):
(Perhaps as an alias too)
Alexander Henket (Jan 23 2017 at 16:29):
ClinicalImpression feels really awkard for conveying the Subjective story that the patient came in with. I think it would cover Objective, maybe Evaluation. I'll forward my question to Patient Care. I'm sure someone worked on this before
Alexander Henket (Jan 23 2017 at 16:40):
GF#12676 added.
Alexander Henket (Jan 24 2017 at 07:06):
-- PS: I noticed that Evaluation is an inappropriate translation of the Dutch term and that Assessment is indeed the correct English term, making SOAP or even SOAPIE the correct acronym.
Marten Smits (Jan 24 2017 at 12:17):
@Ben Schrijver You are working on Profiles for this, could you please remind me which resources we used to cover this?
Alexander Henket (Jan 24 2017 at 12:31):
I asked @Ardon Toonstra and he remembered Observation (so comparable to V3). Not bad but not great either. My gut feeling is something is missing in FHIR here.
Ben Schrijver (Jan 25 2017 at 06:59):
@Marten Smits Initially we used Observation for P, yes. Then we switched to CarePlan, because that seems to make a little bit more sense. But honestly both options feel a bit off, we're still open to better suggestions.
Marten Smits (Jan 25 2017 at 08:46):
Great, thanks for your input
Alexander Henket (Jan 25 2017 at 08:54):
That confirms my thought that we need more solid solutions in this space. @Marten Smits shall we initially try to come up with a plan to get things going? Do we know of more primary care implementers that we can consult, national or international?
Oliver Egger (Jan 25 2017 at 08:58):
Hi @Alexander Henket . In Switzerland I heard also of one primary system implementar where they wanted to develop the SOAP assement scheme in FHIR, I will ask them how they resolved it.
Alexander Henket (Jan 25 2017 at 09:00):
@Ben Schrijver CarePlan could be a reasonable choice, but I think it is overkill in most situations I currently see in practice. Most 'P' entries could be dealt with using just a MedicationOrder, a simple note, a Referral to a hospital etc.
Alexander Henket (Jan 25 2017 at 09:00):
@Oliver Egger Yes please, thanks
Ben Schrijver (Jan 26 2017 at 07:24):
@Alexander Henket Agreed, it's overkill, but we haven't found a better solution yet. Very curious to hear from @Oliver Egger or other people who know of better fitting solutions.
Oliver Egger (Jan 27 2017 at 23:02):
hi @Alexander Henket I got the response back from in4medicine/elexis which implemented the SOAP schema according to the following principles (I made a english translation, maybe not everything is perfect, I’m happy also to provide the german version if somebody is interested) and can relay any info back to them:
“In the Encounter under «indication» conditions are linked. We use the conditions as a subjective entry as well as a problem entry. The distinction which entity is a problem or a subjective is made by the category:
Problem: category = http: //hl7.org/fhir/condition-category | diagnosis
Subjective: category = http: //hl7.org/fhir/condition-category | complaint
The objective entries were relatively unambiguous for us. The related observations are linked to the consultation via encounter and thus can also be queried directly. We use the Observations for everything that can be objectively determined: measured values, laboratory values, social anamnesis and risk factors;
For the assessment entries we used ClinicalImpressions: after recording what the patient told and objective values were held, the doctor's assessment, that is, his "impression" of the matter, comes:
The Clinical Impressions, which belong to the Encounter, have a link to the corresponding Encounter in the context attribute. They can be queried by searching with.
It is therefore still necessary to hold (or interrogate) what is to be done now. To do this, we have discovered the ProcedureRequest resource for us. This also has a reference to the encounter, which can be queried.”
Alexander Henket (Jan 28 2017 at 15:35):
So GP Visit is Encounter
S = Condition (category is complaint) which could be made more formal with a related Condition (category is problem)
O = Observation
A = ClinicalImpression which could be made more formal with a related Condition (category is problem)
P = ProcedureRequest?
-- I'm sure not every GP visit ends with a procedure request? The ZorgDomein solution to have a CarePlan there would works too in some cases. I'm really leaning towards a choice of options here: Reference(CarePlace | MedicationOrder | ReferralRequest | NutritionOrder | ...)
-- How do they handle multiple complaints within the same GP visit? Not uncommon at the GP.
-- Separate of Conditions you create in an Encounter, do you also have an "Episode" / "Problem list" thing that the GP tracks over time and potentially has shifting diagnoses as more information like tests is coming in. E.g. starts with "severe cough", progresses to "bronchitis" and ends in "lnug cancer".
Aurelius Baier (Jan 30 2017 at 09:32):
Hi @Alexander Henket,
I'm one of the persons at in4medicine who specified the fhir interface towards elexis.
I don't understand your expression "category is problem". Do you mean, your system has problems with Conditions when they have categories? Please help me here...
Your summary is correct. Also your note that not only ProcedureRequest may be used as P but also the other resources (CarePlan, MedicationOrder, ReferralRequest, NutritionOrder...) as long as they have a reference to the corresponding encounter. If a system ist that specific, then all these resources have to be queried with the corresponding encounter as search param. In our case, the underlying system (elexis) is just switching from an unstructered encounter text to SOAP, so we did not want to put even more work on their shoulders (and we don't need it yet). If we communicate one day with a system providing other resources than ProcedureRequest as P we will extend our queries. I think that is the way, REST is working (we have to query the ressources one by one instead of receiving everything in one response).
More than one complaint should be no problem: you can put as many conditions in the list as you wish. The graphical presentation of the complaints is up to the client. In our use case (onlinepraxis) we just write one complaint per encounter.
Concerning the problem list: the conditions exist on their own, they are normal, independent resources. So you can query them by category, patient and clinical-status and you receive all the problems/active problems... of that patient. They can also be referenced in the list from several encounters.
I'm open to critics and want to learn more, so please don't hesitate to ask and criticize our approach/suggestion to represent SOAP within FHIR.
Alexander Henket (Jan 30 2017 at 15:12):
I don't understand your expression "category is problem". Do you mean, your system has problems with Conditions when they have categories?
:-) I missed some quotations I see
S = Condition (category = "complaint") which could be made more formal with a related Condition (category = "problem")
..
A = ClinicalImpression which could be made more formal with a related Condition (category = "problem")
Also your note that not only ProcedureRequest may be used as P but also the other resources
Good. That meets my expectations.
More than one complaint should be no problem: you can put as many conditions in the list as you wish.
I'm mostly asking whether or not you can query for "things that happened during an encounter evolving around a Subjective complaint". For that you need some kind of hook, and O & A & P may or may not be tied into that hook
Aurelius Baier (Feb 10 2017 at 09:56):
Hello Alexander
Thank you for the clarification.
I've had a little discussion with the doctor in our team.
As I understand your post, your idea is to use multiple conditions in order to separate multiple topics (problems, reasons for encounter) within the same consultation (e.g. a patients visit for his cough and also for his hurting leg). We think, in theory, the proper way of achieving this separation is by creating two (or more) encounters with links to the corresponding condition of type diagnosis (problem). This way it is very clear and the SOAP schema for formalizing an encounter is kept clean. I don't see how to achieve the same with linking from every SOAP entry to the corresponding problem (condition), the observation seems to have no usable link to the condition.
The question is also, how the doctors work in the real world. Of course, there are exceptions but I think most of them put everything within the same encounter and within the same SOAP entries. Because the encounter (with all the corresponding SOAP entries) is linked to all the corresponding problems, the encounter always is in the result list when querying for one of these problems (searching for an encounter by providing the condition/problem).
As I see now, the future version of the condition valueset will only contain two categories, problem-list-item and encounter-diagnosis: http://build.fhir.org/codesystem-condition-category.html. This leads to changes of our solution because the condition-category « complaint » does not exist anymore. Perhaps it would be possible to extend the observation category valuest with « complaint » ?
Alexander Henket (Feb 10 2017 at 10:19):
Hello Aurelius, in The Netherlands the GP Encounter is a thing with financial consequences. They get paid for the 10-minutes in that Encounter regardless of the number of topics they discuss. So splitting a 10-minute Encounter into as many Encounters as there are problems just because Encounter has to group them, will not work for us in my opinion.
The way GP systems work is that they have a grouping mechanism "Episode" for problem oriented approaches. When something is relevant under a given Episode they add a reference to the Episode to that piece of info, e.g. any combination of S/O/A/P or a specialist letter they receive.
Secondly within Encounter, Dutch GP systems are able to group S/O/A/P based around problem 1 (which may or not yet correspond to an Episode) from problem 2. The Dutch term would be Deelcontact which roughly translates to "Encounter part".
As for the condition category: the binding is an Example binding, so you could completely ignore the proposed valueset. The way the valueset looks right now, I think that is the best thing.
I don't think we have all the answers in place yet. We will probably need more implementation experience to help us find the best way forward.
Lloyd McKenzie (Feb 10 2017 at 21:02):
Encounters are generally specific to the visit and have an administrative and billing impact. If a patient has one visit for 3 problems in the vast majority of healthcare organizations, it wouldn't be possible to define a distinct encounter instance for each problem. How well the model works for SOAP reports isn't a driver for whether encounter instances get created or not . . .
Alexander Henket (Feb 11 2017 at 19:37):
Lloyd, seems you are with me in defining the problem space. Are there any solutions you'd recommend?
Lloyd McKenzie (Feb 12 2017 at 22:55):
I think the intention was that ClinicalAssessment would meet the need. But we haven't profiled it to see how well it does.
Alexander Henket (Feb 13 2017 at 11:54):
"The need": my understanding is that S and A could fit ClinicalAssessment, but O and P seem to match other resources better. O and P would resp. match Observation and CarePlan/MedicationOrder/Referral, although both O and P could be just textual things.
In the V3 world S/O/A are all in principal <observation classCode="OBS" moodCode="EVN"/> with code S-O-A. P could be of the same kind, but seldom is, reverting to SubstanceAdministrationRequest, Referral etc. instead. All other observationEvents in V3 are of type O to us.
P could principally be an Observation with some text, roughly at the level of what a CarePlan could be. That is about as far as current GP CarePlan go for us today. Fully fledged structured CarePlans I have yet to see.
Lloyd McKenzie (Feb 13 2017 at 16:32):
CarePlan can exist as "narrative only". And it can also be contained. And ClinicalAssessment has the ability to point to the relevant "O"s that were used in creating the "A".
Aurelius Baier (May 05 2017 at 13:22):
Alexander, you are completely right. Also in Switzerland the Encounter is a thing with financial consequences and in order to be able to model an encounter where more than one problem is discussed/treated, multiple SOAP tuples should be linked to one Encounter. As I said, not only the patient information system (PIS) towards which we made our FHIR interface, all (major) software systems used in Switzerland by GPs are able to only model one SOAP tuple linked with one encounter. So our solution is far away of ideal but for our situation it works well. In addition, the invoice diagnosis is often the same for several months and for several problems treated.
What is that ClinicalAssessment? I've not found it within the resources of FHIR.
Concerning narrative only: that is how mutliple problems treated during one encounter normally are documented in the PIS: all S entries S within the Subjective entry and so on. One SOAP for mutliple problems.
We would also be interested in adapting our solution towards a better way to do it.
Last updated: Apr 12 2022 at 19:14 UTC
