EMIS Partner API - FileRecord call - creating linked SNOMED codes

open forum
1

Hello,

I’m integrating our product with the EMIS Web Partner API, but I’ve hit a snag with filing pre-existing codes with FileRecord.
The idea is, patient records have existing codes. When we file a consultation, the selected pre-existing codes should ideally pop up as ‘review’ instead of ‘new’, as that would mitigate flooding the patient’s problem section with codes.

We try to construct the <ConsultationElement> as follows. Note the attempt to use <ProblemLinkList> instead of <Problem>:

<ConsultationElement>
    <RefID>3</RefID>
    <Header>
    <Term>Problem</Term>
    </Header>
    <Event>
    <RefID>3</RefID>
    <GUID>d3d98838-cb0c-4caf-8811-bbdd5c0d233c</GUID>
    <AssignedDate>29/09/2025</AssignedDate>
    <AuthorID>
        <RefID>2240</RefID>
    </AuthorID>
    <OriginalAuthor>
        <User>
        <RefID>2240</RefID>
        </User>
        <SystemDate>29/09/2025</SystemDate>
    </OriginalAuthor>
    <DisplayTerm>Renal impairment</DisplayTerm>
    <Code>
        <Value>236423003</Value>
        <Scheme>SNOMED</Scheme>
        <Term>Renal impairment</Term>
    </Code>
    <TermID>
        <Value>236423003</Value>
        <Scheme>SNOMED</Scheme>
        <Term>Renal impairment</Term>
    </TermID>
    <EventType>1</EventType>
    <ProblemLinkList>
        <Link>
        <Target>
            <DBID>47</DBID>
            <RefID>47</RefID>
            <GUID>2453A107-0B5E-457E-BE94-7905334CF965</GUID>
            <FileStatus>0</FileStatus>
        </Target>
        <LinkType>1</LinkType>
        </Link>
    </ProblemLinkList>
    </Event>
</ConsultationElement>

When looking at the corresponding patient’s record, here’s how the same code appears:

<ConsultationElement>
    <FileStatus>0</FileStatus>
    <DisplayOrder>1</DisplayOrder>
    <ProblemSection>0</ProblemSection>
    <Header>
    <Term>Problem</Term>
    </Header>
    <Event>
    <DBID>36691332</DBID>
    <RefID>36691332</RefID>
    <GUID>{94635657-0B76-47D5-B5CC-C5B75F1A27C9}</GUID>
    <FileStatus>0</FileStatus>
    <AssignedDate>28/09/2025</AssignedDate>
    <DatePart>0</DatePart>
    <AssignedTime>00:00:00</AssignedTime>
    <AuthorID>
        <DBID>1295</DBID>
        <RefID>1295</RefID>
        <GUID>{E7D0737C-0922-448F-A3F2-9D3B8E232CE2}</GUID>
    </AuthorID>
    <OriginalAuthor>
        <User>
        <DBID>1295</DBID>
        <RefID>1295</RefID>
        <GUID>{E7D0737C-0922-448F-A3F2-9D3B8E232CE2}</GUID>
        </User>
        <SystemDate>28/09/2025</SystemDate>
    </OriginalAuthor>
    <DisplayTerm>Renal impairment</DisplayTerm>
    <DescriptiveText />
    <PolicyID>-1</PolicyID>
    <Code>
        <Value>K060.</Value>
        <Scheme>READ2</Scheme>
        <Term>Renal impairment</Term>
        <MapCode>236423003</MapCode>
        <MapScheme>SNOMED</MapScheme>
    </Code>
    <TermID>
        <Value>K060</Value>
        <Scheme>READ2</Scheme>
        <Term>Renal impairment</Term>
        <MapCode>236423003</MapCode>
        <MapScheme>SNOMED</MapScheme>
    </TermID>
    <Abnormal>0</Abnormal>
    <EventType>1</EventType>
    </Event>
</ConsultationElement>

Clearly this attempt failed.

Is what we are attempting to do with FileRecord impossible? Or are we doing it wrong? The idea is to file codes, where appropriate, as review.

@mayfield.g.kev hoping again that you’ve trodden this path before.

Thanks in advance,

Faraz

2

The fix has been found.

When linking codes, the following must be included:
<Problem> … </Problem>
<ProblemLinkList> … </ProblemLinkList>
<Episodicity>3</Episodicity>

3

Thanks @imfarazmalik for marking the topic as solved.

If openhealthhub.org has been of help to you then please do spread the word about it!

Also, I’m not sure if you are aware but there is now also an NHS Developers Community forum, which in recent years has probably become more of a focus for queries and discussion around NHS APIs. Of course, in this case your query was with an EMIS API, but the link below may be of help for other queries.

4

That forum is useful but it tends to be NHS England APIs only and relies on the NHS England team behind the API getting involved.

The far wider set of NHS “standard” APIs, messages and event feeds isn’t covered.

5

Thanks @mayfield.g.kev - do you think OHH is a good place to cover off the other stuff? And if so how do we get the message out there more widely? I guess OHH is one of the few places that a Google search for EMIS APIs is going to get hits of any useful nature, so there might be some organic traffic that way.