# Encounter Resource in FHIR (Care Connect) Server Profile **Category:** [FHIR](https://openhealthhub.org/c/fhir/31) **Created:** 2018-10-09 09:04 UTC **Views:** 5899 **Replies:** 23 **URL:** https://openhealthhub.org/t/encounter-resource-in-fhir-care-connect-server-profile/1817 --- ## Post #1 by @Tharma Hi, How can we identify the actual event / state of the resource from the Encounter resource? for example, The Encounter delivered to the PUT method might be due to a unit transfer in the other system or due to discharged ? going through the Encounter structure, but couldn't identify the exact element? please share your thoughts. thanks --- ## Post #2 by @mayfield.g.kev I'm working on an example of this at the moment. My thoughts I would create a master Encounter (say emergency episode) This would have child encounters such as: * Triage Encounter * Ambulance assessment encounter * Ambulance transport encounter * Ambulance handover encounter These sub encounters would use Encounter.partOf to reference the master Encounter. For a hospital, following this approach I would have: Hospital Episode Encounter which consists of a number of speciality (e.g. Emergency, Inpatient, etc) Encounters (episode?) and these break down into other Encounters which detail the admission, transfer, discharge and other interactions with the patient. (These would correspond partly to ADT^A01, ADT^02, ADT^A03, ADT^A04 etc) However I believe the top level Encounters (for both Ambulance and Hospital) should really be FHIR EpisodeOfCare. --- ## Post #3 by @mayfield.g.kev Initial example. Main Encounter (id=1383 aka the Episode) and two child encounters (id = 1386 and 1387) The ambulance encounter is in progress and is carrying the patient to jimmies @ Leeds Teaching Trust ``` ``` --- ## Post #4 by @mayfield.g.kev Note the use of partOf in the child encounters. --- ## Post #5 by @Tharma Hi, Interesting, Yes this will be helpful if we are going to persist the encounters in FHIR repository. How this could be achieved with connecting existing PAS + APIs. for example we receive a FHIR encounter resource (In Patient encounter) via PUT which represents a patients transfer from one ward to the other happened in at specific time. here we need to identify these (transfer time, patient new location etc) and record as a transfer in the PAS ? thanks --- ## Post #6 by @mayfield.g.kev Are these coming as HL7v2, FHIR messaging (such as digital child health or events) or FHIR REST API? --- ## Post #7 by @Tharma its FHIR REST API. thanks --- ## Post #8 by @Tharma can we assume like this ? when the encounter received via PUT, to determine the corresponding workflow / event related to the encounter, we might need a logic on the encounter as bellow, when the encounter.id is same then its update encounter, when the encounter is new and location is different then Transfer when the encounter is new and status is performed then discharged ? And when the sending application is always dealing with single encounter (visit/contact) for all these workflows it can use the FHIR Extension or modifier extension to send the event information transfer/discharge etc ?http://hl7.org/implement/standards/fhir/extensibility.html#modifierExtension share your thoughts please thanks --- ## Post #9 by @mayfield.g.kev I'm not sure about using id though - it works if the source system is acting as a client and knows the server id's. If it doesn't know the server's id's then using identifier may be more useful. Here you could use a conditional put `PUT http://fhir.example.com/Encounter?identifier=system%7C1234` Update Encounter with identifier of 1234. Both transfer and discharge would be PUT's but with different status (and/or class) discharge status = finished transfer status = in-progress (class = https://snomedbrowser.com/Codes/Details/107724000 ) ** arrival or consultation started should be POST using the 'If-None-Exist' header e.g. POST http://fhir.example.com/Encounter If-None-Exist: Encounter?identifier=system%7C1234 Using identifiers would also help compatibility with HL7v2 systems where majority of Encounters updates would be handled. Another option, especially if its workflow is to use FHIR Messaging. Bundle has the option of setting the HttpVerb at Bundle.entry.request (http://hl7.org/implement/standards/fhir/bundle.html) ** I think a transfer would be an Encounter in it's own right --- ## Post #10 by @Tharma hi Kevin, encounter.status == finished, yes I understand this. ** I think a transfer would be an Encounter in it’s own right - actually can this be a same encounter if the sending application uses single encounter (Visit) in their system from admission to discharge ? when it comes to transfer, should we deal with encounter status or location status ? 1) I am afraid am missing something here . how could we use the encounter status to track the transfer when patient move from Ward A to B and then C ? for these two transfers, encounter.status would be same always ? thanks --- ## Post #11 by @mayfield.g.kev I'm following this up elsewhere. If you are familiar with ITK HL7v2 my belief is the PV1 roughly corresponds to an individual FHIR Encounter. So the PV1 for an Admission is one Encounter, PV1 for Transfer is another Encounter They are all linked either by a master Encounter (or EpisodeOfCare), this master would match up to the VisitId (PV1:19). This master encounter/episode would be used to link up the admission, ward rounds, medication administration, transfers and discharges. (i.e. its catering for more than ADT) So when an Discharge Encounter or ADT^A03 is received it would update the parent Encounter(Episode). --- ## Post #12 by @mayfield.g.kev ![ADT%20FHIR|690x329](upload://7qOuTBqGM8yqVyDnPQuh0MDp3wf.jpeg) To illustrate what I was saying, actions such as an admission, discharge or transfer, would be a new/create Encounter (detail). Internal processing would update the parent Encounter (Master) and/or EpisodeOfCare - is some complexity here and depends on how the PAS works. If these are updated then this would be a PUT on the Encounter (detail). So if a patient was transferred to a hospital from the ambulance service. A rough set of interactions could be: 1. POST ReferralRequest (ambulance tells hospital a patient is being transferred) Hospital creates an EpisodeOfCare and Encounter-Master (class emergency - status planned) 2. Ambulance arrives (Encounter-Detail created, ADT^A04 sent, Encounter-Master updated) patient treated (0..many Encounter-Details created) 3. Emergency treatment ends and patient is transferred to ward (Encounter-Detail created (type - transfer) plus ADT^A02 and also create Encounter-Detail discharge plus ADT^A03, ??? end Encounter-Master) 4. Patient admitted (Encounter-Detail created (type - admission), ??? new Encounter Master (class - inpatient) 5. Patient discharged (new Encounter-Detail discharge, update Encounter-Master (ended) and end EpisodeOfCare, triggering a discharge letter. So the hospital has one Episode Each hospital team (ED, ward, etc) has one Encounter-Master Every action has one Encounter-Detail (clinical content is recorded against this) It's looking more complicated than HL7v2 but ADT tends to focus on the administration side and FHIR Encounter is focused around care provision and actions. --- ## Post #13 by @Tharma when going through more on FHIR, I found [http://hl7.org/implement/standards/fhir/workflow.html](http://hl7.org/implement/standards/fhir/workflow.html) is this relevant to what we discussing here ? --- ## Post #14 by @mayfield.g.kev I think that's more to do with ordering a service (procedure, diagnostic test, etc) but the resulting delivery of that order would more than likely be documented via an encounter. We've got a few examples of Encounters on this patient https://data.developer.nhs.uk/ccri/ed/patient/1183 The Encounter on 12-Feb-2015 is available via restful API (see encounters tab) and also in FHIR document form (documents tab). --- ## Post #15 by @Tharma Hi Kevin, When it comes to planned inpatient admission with the following use case, 1. Referral received for the patient - (Fhir.Referral created) 2. Referral is assessed and accepted - (Fhir.Referral status updated and Fhir.'EpisodeOfCare' created ) 3. Patient is put on waiting List (appointment is given after 5 weeks ) - (Fhir.Appointment is created) 4. Appointment is updated as To Come In (two days before) with number of nights 3 and bed is allocated. (Fhir.Appointment is updated) 5. Patient admitted for Treatment for 3 days - (an on going Fhir.Encounter is created) 6. Updates to admission, transfers etc (more encounters created / updated) 7. Patient is discharged gone home after treatment. (Fhir.Encounter updated as finished) are the above mappings correct with the corresponding Fhir Resource for each step in the workflow ? please correct if I missed anything ? thanks --- ## Post #16 by @mayfield.g.kev I need to get back to you on that (busy at moment) but I belive something similar ADW (admission, discharge and ?waiting list?) is being worked on at present by NHS Digital. --- ## Post #17 by @mayfield.g.kev I've had a look at Social Care ADW (https://data.developer.nhs.uk/specifications/sc-fhir-5/Chapter.4.Messages/index.html) and the pattern of messages matches a number of points of your workflow. It uses social care terminology for a referral, assessment. The overlap is: 1. Referral received (Assessment Notice) 2. Referral assessed and accepted (Assessment Notice Accepted or Rejected) 7. Patient is discharged home after treatment (Discharge Notice - I'm not sure this a correct mapping. I feel this should say the Referral request (the order) has been completed) I think thats the beginnings of a basic workflow for referrals (it's also in INTEROPen Michael's storey). Generic (fag packet) pattern: I create an order, this is accepted or rejected and the order is completed. Appointments is a similar order pattern with some extra's. This API is for unscheduled care but from what I've heard it's possibly a generic solution https://nhsconnect.github.io/FHIR-A2SI-APPOINTMENTS-API/index.html I've still not got a generic answer for Encounters but still looking at it. The attached screenshot is from INTEROPen Michael's storey. ![50|690x300](upload://zRIaLVkUBdnpF82hfuYIG4pcI9m.png) It's currently more of a clinicians view of an emergency and inpatient episode but I'm looking at adding patient administration (HL7v2 friendly) content. You can access the HIE here: https://data.developer.nhs.uk/ccri/ed/ Issues at present: it's not clear that the patient was discharged from emergency care and inpatient care, when the patient was admitted. Should add in a transfer (patient move from ED to ward). --- ## Post #18 by @mayfield.g.kev Just to add.... the HIE is a work in progress and is being actively worked on for the INTEROPen hackathon this week. --- ## Post #19 by @Tharma The references in Encounter, for example Location and Participant / Practitioner Resources in Encounter. Can Encounter have the logical references for the these resources, for example NHS Location code for Location and GMC code for the practitioner ? https://hl7.org/fhir/2018May/references.html are there any change in the care connect profile from the standard related to this ? thanks --- ## Post #20 by @mayfield.g.kev If you look at the NRLS specs they are using 'logical' references. https://developer.nhs.uk/apis/nrls/api_interaction_create.html So for Leeds Teaching trust they have used <reference value="https://directory.spineservices.nhs.uk/STU3/Organization/RR8"/> but that logical reference resolves correctly. However this patient reference doesn't <reference value="https://demographics.spineservices.nhs.uk/STU3/Patient/9876543210"/> As a developer I like this, it stops me from creating resources for well known identifiers (which means I don't have to do as much work building a Bundle and it still reads correctly. As an experienced developer I can see the above are NHS Number and ODS code). It's not the R4 way of handling logical references. --- ## Post #21 by @mayfield.g.kev We've added examples with serviceType (backport from R4). See https://data.developer.nhs.uk/ccri/ed/patient/1192/encounter We've used a DCH CodeSystem for MainSpecialty/TreatmentFunction/ITK HL7v2 table 0069) which isn't ideal. --- ## Post #22 by @dunmail I think this approach is OK, so long as there is an intent that the references are eventually resolvable (in an NHS timescale rather than a new software engineering concept that I invented). Nothing stopping them being backed up with the type/identifier as well so that can underpin search on other endpoints i.e. {base}/{type}?identifier={identifier} --- ## Post #23 by @mayfield.g.kev I'm currently working on this. Have raised some comments on INTEROPen ryver https://interopen.ryver.com/index.html#forums/1323058/chat --- ## Post #24 by @mayfield.g.kev p.s. I think I'm going to go against my comments above and be more focused on a strict HL7v2 view of the world. --- **Canonical:** https://openhealthhub.org/t/encounter-resource-in-fhir-care-connect-server-profile/1817 **Original content:** https://openhealthhub.org/t/encounter-resource-in-fhir-care-connect-server-profile/1817