Stream: implementers
Topic: Encounter
David Hay (Mar 08 2016 at 00:57):
Where's the recommended place to put the 'specialty' in an encounter. eg that the patient was admitted under Cardiology. (I think I asked this before, but if so have forgotten the answer 
Jayashree Surnar (Apr 11 2017 at 04:58):
hello all, in our ipad appln we want to display building, wing, ward, roo, bed fields from location resource. and that location is attached to Encounter(admission info).
as per the Location resource here we can create 5 instances.
hierarchy is like this
building(instance) as part of buliding we can keep wing(instance) and as part of wing ward is there ...
so if we do like this, we need to create so many resources.to avoid this what we are thinking is just create the extensions for building, wing, ward, room, bed and then add it to location resource or can we create an extension(complex) called Location by adding building, wing, ward, room, bed as child elements to it and then add this extension to Encounter?.
2nd question is: we want to add serviceCategory, serviceType,speciality from appointment as Extensions to Encounter resource. and remove appointment from Encounter. and in HealthcareService also we have these 3, and we can add HealthcareService as reference to PractitionerRole so again here what i'm thinking is we can add these 3 to PractitionerRole as Extensions?
3rd: from the Encounter we want to refer a DocumentReference which referes CCDA. and also claim recource. how to inplement this?
so please any suggestions? whethere it is correct or not? if not, how to do?
thank you.
Sunanda Veeraganti (Apr 11 2017 at 12:58):
@Jayashree Surnar you can create Building instance, Wing instance and so on. Connect all of them using the field Location.partOf. This way you don't need to create extensions or child elements. Encounter Resource can reference the resource location.
Sunanda Veeraganti (Apr 11 2017 at 13:01):
Regarding your second question it is easy to reference appointment resource in encounter. Rather than pulling two fields and creating a new extension in encounter resource
Jayashree Surnar (Apr 11 2017 at 13:21):
@ sunanda Veeraganti, ya we can do. but what we are thinking is if we do like that we have to create lot of instances, so i'm thinking alternative(better way).
Sunanda Veeraganti (Apr 11 2017 at 13:31):
The purpose FHIR is interoperability. If too many extensions are created then the purpose will be lost.
Lloyd McKenzie (Apr 11 2017 at 14:44):
Agree with @Sunanda Veeraganti. There's always more efficient ways of meeting a particular local requirement than strict adherence to the standard - but that comes at the cost of not being able to interoperate. At the same time, if it feels like the standard is making a legitimate implementation need too onerous to implement, it's quite reasonable to push back on the standard and ask for an easier way.
Jayashree Surnar (Apr 12 2017 at 04:05):
Thanky you @ sunanda Veeraganti and @Lloyd McKenzie
Jayashree Surnar (Apr 12 2017 at 04:10):
@Sunanda Veeraganti you said, The purpose FHIR is interoperability. If too many extensions are created then the purpose will be lost. i agree with you. but one more doubt regarding the Location. without creating the extension can we add building, wing, ward, room, bed as elements and map it to Location.text an then create Location profile? what do you say? Thank you.
Sunanda Veeraganti (Apr 12 2017 at 09:33):
@Jayashree Surnar You can use Location Type and use the value set for Location Physical type. See this page for more information https://www.hl7.org/fhir/valueset-location-physical-type.html
Jayashree Surnar (Apr 12 2017 at 10:29):
@Sunanda Veeraganti , yah. i saw that. but what our TL asking is, can we just add all the above fields individually to Location. so that we can maintain only one Location instance.
Sunanda Veeraganti (Apr 12 2017 at 10:31):
You can use one location instance and use the Valueset of location physical type
Lloyd McKenzie (Apr 12 2017 at 14:04):
@Jayashree Surnar I think the guidance right now is that if you want to convey a Location and as part of that convey the full "hierarchy" of identifiers, you'd use contained Locations for all of the partOf relationships. The challenge with that is that 'contained' is supposed to be used when the instances can't stand alone, and the ward/room/building Locations probably can stand alone. As a result, I think it is reasonable to submit a change request asking for discussion of this point - I don't think it's an uncommon need and we don't want to make it too clunky.
Jayashree Surnar (Apr 13 2017 at 04:33):
ok, Thank you @Lloyd McKenzie
previous as you said, y ou can create Building instance, Wing instance and so on. Connect all of them using the field Location.partOf. Encounter Resource can reference the resource location.
so we decided to do that, but here my doubt is, for example if we have 2buildings, 200 rooms, 1000 beds. then we suppose to create these many instances right? if this is not a big issue, we can go with this.
other wise, will submit a change request asking for discussion of this point. what do you say?
Lloyd McKenzie (Apr 13 2017 at 04:44):
Well, in principle, hospitals will indeed have instances for all of those things - as every bed, room, etc. will have a status. Rooms may have phone numbers. Each bed and room will need to be uniquely identifiable to indicate what equipment is available, etc. So separate instances is reasonable.
Jayashree Surnar (Apr 13 2017 at 04:45):
Thank you very much. @Lloyd McKenzie
Simone Heckmann (Apr 13 2017 at 05:50):
I have been wondering: Aren't there beds/rooms that may be shared between wards? If the actual association can alter depending on the type of patient occupying it, we currently have no way of expressing this, right?
I don't really like the Idea of containing the locations. They are very common search criteria, like "give me a list of all Patients in ward x", "Who is currently occupying Room z"? In contained resources, these attributes are out of reach to run a search on.
Simone Heckmann (Apr 13 2017 at 05:56):
Also: I believe that there are quite a lot of systems that don't care for Locations details down to the bedplace and are satisfied with knowing the ward. The way it is now, they'd have to go up the hierarchy three or more hops to figure that information out.
Those systems that come from a V2 background and are used to picking their required information from a PV1.#3 subfield may find that approach somewhat complicated.
I'd be very much in favor of having either a backbone element in Encounter or a set of extensions, that allows the information that resides in PV1.#3 to be referenced directly from the Encounter.
Simone Heckmann (Apr 13 2017 at 07:04):
I imagine that if you model Encounter.location as a Bedplace being part of a room being part of a ward, listing all Patients within a particular ward (which is a very common thing to do, I suppose) might be quite costly on the server side, no?
Jayashree Surnar (Apr 15 2017 at 06:23):
hello all, actually i'm new to fhir so g etting more doubts if these are silly things just don't mind.i'm discussing this topic from few days.but still in dialoma. so please help.
comming to topic:
we want to capture location,service,participant info as part of patient's admission screen.
for this i have gone through the fhir resource like Organization,location,Healthcareservice,practitioner.
what i understand is we can use organization resource to create the department and
location resource to create bulding,wing,ward,room,bed.
for service which resource we can use? and whats themain purpose of HealthcareService?
here my biggest doubt is, if we create 1000's of instances then what's the speed of the application?(we are implementing the mobile app.)because as we are using these many resource so we need to do lot of API calls for individual screen right?
Lloyd McKenzie (Apr 15 2017 at 23:39):
"service" can mean all sorts of different things, so best to describe exactly what you're looking to capture with some examples.
Lloyd McKenzie (Apr 15 2017 at 23:42):
There will certainly be thousands of instances (hundreds of thousands for even small clinics, well into the 100s of millions for decent sized hospitals once you think of every single blood pressure or other measurement for every single patient. But your phone doesn't have to hold all of those - that's the work of the server. Your phone only needs to grab the specific locations, organizations, etc. that are relevant to the specific encounters you care about. And you should be looking at a much smaller number (in the 10s or so)
Jayashree Surnar (Apr 17 2017 at 06:36):
@Lloyd McKenzie , regarding service, can you see this valueSet once.
https://fhir-ru.github.io/valueset-service-type.html
(we required these services. to provide these, which resource should we use?)
if we use these many resources, what about API calls?i mean how to reduse the API calls?
Jayashree Surnar (Apr 19 2017 at 04:07):
Good Morning All,can any one explain what's the relationship(or link) b/w the resource Encounter And Episodeofcare ? i'm not understanding the workflow of Episodeofcare. so please help.
Thank you.
Lloyd McKenzie (Apr 19 2017 at 05:00):
An encounter can be part of an EpisodeOfCare. So, for example, a GP visit can be part of a pregnancy episode, or a radiation visit can be part of an oncology episode. An EpisodeOfCare groups all care associated with a particular condition/problem occurrence.
Jayashree Surnar (Apr 19 2017 at 13:10):
Thank you @Lloyd McKenzie , what i understood is for each condition(diagnosis) we are creating EpisodeOfCare and in Encounter also we have diagnosis. so what is the difference? how EpisodeOfCare is useful? if i ignore EpisodeofCare implementation in our client(ipad app) then what? is there any effect?
Lloyd McKenzie (Apr 19 2017 at 14:59):
Not all encounters that you tie to an episode will necessarily point to the same Condition instance. For example, if you admit a patient for hypertension, that may still be relevant to their pregnancy episode.
Jayashree Surnar (Apr 21 2017 at 05:08):
@Lloyd McKenzie , so we can ignore client side(in ipad app impl) implementation of EpisodeOfCare. it's not a problem right?
Lloyd McKenzie (Apr 21 2017 at 06:26):
You can ignore any resource you wish if your user community doesn't need it/care about it
Jayashree Surnar (Apr 21 2017 at 08:05):
okay. thank you @Lloyd McKenzie .
Jayashree Surnar (May 05 2017 at 07:11):
hi every one, when i send this data to hapi server using Advance Rest Client in Encounter subject(patient) is not storing. and i send immunization also in that case patient is storing. whats the problem?
Lloyd McKenzie (May 05 2017 at 15:40):
I'm not sure what an "Advance Rest Client" is. What server are you sending to? What exactly are you POSTing? What response are you getting back?
Mounika (Aug 03 2018 at 13:42):
Hi all,
Currently we are using Encounter types valuesets CPT Codes (http://www.ama-assn.org/go/cpt).
But while we create main Admission encounter which value sets we need to use.
Can you please suggest.
Thank you in Advance
Keerthivasan Ramanathan (Jun 02 2020 at 10:08):
is 'AMB' can be used for Encounter.class for outpatient encounters?
Lloyd McKenzie (Jun 02 2020 at 13:42):
Yes. As per the definition, Ambulatory and Outpatient are considered synonyms.
Shweta Rajput (Jun 03 2020 at 07:45):
Hi all,
I am new to FHIR and I am creating a new Encounter resource but I am having error while creating it. the error is :
"severity": "error",
"code": "processing",
"diagnostics": "Profile http://hl7.org/fhir/StructureDefinition/Encounter, Element 'Encounter.class': minimum required = 1, but only found 0",
"location": [
"Encounter",
"Line 1, Col 2"
]
the JSON Encounter resource look like this :-
{"resourceType":"Encounter","identifier":[{"use":"secondary","type":{"text":"Episode Visit No."},"value":"1"}],"status":"in-progress","serviceType":{"id":"102","text":"Dermatology"},"subject":{"reference":"http://10.226.24.189:8080/hapi-fhir-jpaserver/fhir/Patient?_id=2"}}
Can anyone please help me with this?
Thank You in Advance.
Mareike Przysucha (Jun 03 2020 at 07:59):
A quick first answer, as I don't have time: An Encounter needs the attribute class. Your resource doesn't have one, so you need to add a coding for this attribute. (see https://www.hl7.org/fhir/encounter.html)
Shweta Rajput (Jun 03 2020 at 09:26):
Hi Mareike,
Thank you so much for prompt reply...
that hint really helped me. The problem is solved now.
Mareike Przysucha (Jun 03 2020 at 10:03):
Perfect, I'm im glad I was able to help you. Sorry for the quick reply, my students were waiting. Greetings.
Domina Tang (Jun 03 2020 at 20:24):
@Shweta Rajput From the error message, your JSON data missing "diagnostics" property, at least one diagnostic is required.
Domina Tang (Jun 03 2020 at 20:30):
(deleted)
eyal wolanowski (Jun 16 2020 at 12:25):
What is the correct way to implement a query that returns all the encounters ordered by the last encounter.statusHistory.period.end
Lloyd McKenzie (Jun 16 2020 at 12:27):
You'd have to define a custom SearchParameter for Encounter.statusHistory.period.end
sandeep diddi (Jul 27 2021 at 11:25):
All, When we create Resource Types (Encounter) here is a expected feild reference for a Subject
"subject": {
"reference": "urn:uuid:9e43a3bf-fb4f-4007-8a1f-d8e00e57d4e5",
"display": "Test"
},
I read from Hl7 and it says the reference comes from other server. Did not really understand that. Any thoughts on what this reference is ?
Lloyd McKenzie (Jul 27 2021 at 13:03):
The Reference needs to point to the Patient instance the Encounter is associated with - where is the Patient for your encounter stored?
Akira Kakkar (Nov 02 2021 at 11:44):
I want to get list of encounters (filtered by dates) with name of practitioners associated.
Currently, calling GET practitioner by Id from after calling GET encounters.
This is working fine but not great in a sense that if I have 100 encounter in encounters list, I have to do 101 (1 get encounters and 100 practitioner names) api calls. Is there any alternative sol'n for this or I just need to swallow this and use caching layout.
Maybe I am thinking too much form the perspective of sql as I just need to do join call to reduce number of api calls
Michele Mottini (Nov 02 2021 at 11:57):
Use an include: [base]/Encounter?date=....&_include=Encounter:practitioner
Daniel Venton (Nov 02 2021 at 11:58):
I think it's supposed to be /Encounter?_include=Encounter:participant but maybe both work?
Akira Kakkar (Nov 02 2021 at 12:00):
Thanks. I didn't know about _include feature. This is very handy. Let me try it out.
Daniel Venton (Nov 02 2021 at 12:09):
You could also do a single call for practitioners /Practitioner?_id=id1,id2,id3,id4,id5.......
Robert P (Nov 02 2021 at 15:35):
Is there an API for patient’s arrival to OR to wheeled into OR essentially?
Robert P (Nov 02 2021 at 15:35):
(deleted)
Francesca Ricci-Tam (Nov 02 2021 at 16:10):
Daniel Venton said:
You could also do a single call for practitioners /Practitioner?_id=id1,id2,id3,id4,id5.......
Is there a limit on the number of id's one can join in a single API call?
René Spronk (Nov 03 2021 at 07:41):
No limit (at least: not a limit specified by FHIR itself, a FHIR server may have its own limit). Although you may wish to use a List (FHIR resource "List") based search string if you'll be repeatedly using the same set of ids.
Lloyd McKenzie (Nov 03 2021 at 13:56):
Some servers may have a maximum URL length, in which case you might have to submit your search via POST instead of GET. And even using POST, some servers may enforce safety limits of some sort.
Last updated: Apr 12 2022 at 19:14 UTC
