Sending Letters to GP's - Document Handling

open forum
#1

I’m working on changing over our DTS clients to MESH at the moment but wondered what we can do to be Transfer Of Care future proof.

As I understand it, we can do the following to send letters to GP’s

EMIS - Kettering XML format via DTS (?html)
INPS - Kettering XML format via DTS (?html)
TPP - Kettering XML format via DTS (we use this but only for community referrals - document format HTML)
EMIS - ITK XML with ITK SOAP - payload CDA including PDF document (or html?)
DOCMAN (so both EMIS and TPP) - Kettering XML format via DTS (?html)

Is this correct?

The documents we get in tend to be either from file drops or HL7v2 with the document formats pdf, html or rtf.
Metadata is equally a mixed bag but I use FHIR DocumentReference as it can be easily converted to ITK XML/CDA, IHE XDS, Kettering, DTS etc (if you manage your metadata). As we use HL7 FHIR internally, I prefer HL7v2 feeds as it’s a simple mapping exercise and it also works very well with the mixed bag of file feeds/formats.

So:

IN - File or HL7v2
TIE/Middleware - HL7 FHIR
OUT - Kettering XML+DTS or ITK/CDA (IHE XDS is also possible)

Format - Answer seems to be documents should be html format? and use FHIR to decouple middleware/business logic from the OUT formats (i.e. don’t design middleware around the endpoint or source formats). It also allows move from Kettering+DTS to ITK+CDA
Reason for html: easier to convert to PDF and transform to basic CDA.

Suggestions welcomed.

p.s. Another reason for using a different middleware format. We send these documents to an Document Management system. So by converting our IN documents to FHIR we quickly support multiple output systems - rather than build a point to point system for each interface.

#2

Pretty much, apart from DocMan which I can’t comment about.

The main reason for HTML being a de facto standard for the document blob is it is (was) the only format supported for ingestion by the big two suppliers (the only two we currently need consider in Leeds area).
It causes us an extra unnecessary rendering step as the discharge docs are already available in PDF in our PPM+ EPR, and is an issue for any source systems that can only provide PDF output.

For ToC future proofing, well for phase 1 just ensure the content is in the AoMRC headings. For later phases CDA but depends on the source systems supplying the SNOMED and dm+d coding.

How’s that community referrals production going?

#3

Your not expecting the CDA ToC document from the EPR are you? Presume you’re building it within the TIE.

I was looking at the new proposal yesterday and it struck me that it wouldn’t be possible to build the CDA from an EPR. It (or digital dictation) would provide narrative and some data items, a significant number yes but not all. Other data items would need to be added as part of a workflow process (so either in a TIE or BPMN engine).

With that in mind it would be really useful to have a set of standard API’s to call to asemble the CDA, i.e. something like what FHIR gives. If that’s going to be the case for most systems, why not expose the API’s to GP systems. Understand this won’t happen for transfer of care but it’s a probable future state (discharge letter concentrates on discharge instructions and patients coded data is accessed real time on demand).

#4

Hi Kev, the formats for sending to GPs are fine for this year, but no Kettering next year, moving to CDA.

Transfer of Care for Dec 1st 2016 is for Acute & Mental Health Providers deliver e-Discharge for In-patient & Day Case to GPs:
- AoMRC headings
- Electronic format (No paper, no fax)
- Strong recommendation to move to ITK CDA

Transfer of Care for Dec 2017 has to deliver:
- AoMRC headings
- Nationwide delivery of e-Discharge (i.e. Out of Area e-discharges)
- Structured Message (ITK CDA)
- Capability to carry coded procedures; diagnosis, allergies & adverse reactions and
medications

EMIS, TPP & InPS are already Level 1 CDA accredited; i.e. they can receive CDA Level 1 (narrative)

For Transfer of Care ‘future proofing’ think about
- ITK/CDA, as the NHS Standard Contract is likely to change.
- Use of SNOMED terminology by 2020

There are a number of webinars, clinical and technical where further information is provided.

Register here: http://systems.hscic.gov.uk/interop/tci/edischarge

#5

Thanks James,

I’m a bit skeptical these targets will be met. A mixture of reasons but mostly HL7 CDA and ITK on top is a massive change from where the average trust is at the moment.

#6

Along the lines of this : https://github.com/cdaapi/cdaapi_core perhaps?

#7

Yes or the green CDA approach?

Has been relatively painless to get documents (HL7v2) from our new EPR to our Document Management system and also wire that into a test MESH(DTS) feed (all about 2 days work).
If I could take these feeds (currently FHIR / IHE MHD) and convert them to CDA via an API or transform, that would be ideal.

#8

Kev, if your question was how do we do it at LTH, no we don’t build the CDA in the EPR.

The EPR builds the human readable document as an e-form (in XForms XML), for display and editing during the workflow then renders it to PDF for viewing when the document is saved. For transmission to GP it passes the XForms document via a DB query to the integration engine with some metadata, the RIE then creates the CDA. It works but we’re looking at a more canonical internal API between EPR and integration engine and will probably adopt FHIR.

However in our case the EPR does (or will) have all the data for the ToC. Theatres info is currently re-typed from a different application but we’ll address that via HL7v2 messaging shortly. Medications and allergies are done via API from the e-Prescribing system. There’s an ongoing question/debate about the source of truth for allergies, as e-Prescribing only does drug allergies at present.

In a future state it’s likely a “Transfer of Care” will be just an event and the “document” will be assembled on query from its constituent bits of clinical data: Medications, allergies, procedures, clinical notes, etc Which will probably be obtained as pointers from one or more record locator services. So yes this will necessitate standardised APIs to retrieve key bits of clinical data to assemble a transfer of care “view”.

#9

Thanks Adam.

I’ve just sent you the latest info PRSB headings - believe it’s a newer version.

Our systems have a lot of similarity, broadly speaking we are not expecting an EPR or PAS to generate CDA and the workflow engine or TIE will assemble the document. Would expect some trusts to generate CDA from the EPR/PAS especially where they have an EPR covering all bases but in many cases the CDA will need to be assembled from multiple systems - which implies it would be helpful if we had a common set of API’s, i.e. FHIR.

#10

Interested in this thread as I’m a lay person technically (pharmacist) trying to figure out (with our dev agency) a simple, secure interim way to send a letter/prescription request document from our third party community pharmacy app into EMIS/Tpp workflow or document management as by the time GPSOC pairing takes way too long. Have looked at Docman but ongoing cost per transmission is prohibitive for pharmacy model. MESH seems ideal as just initial setup investment needed but figuring out how big a job it is to set-up seems impregnable! e.g. is an N3/HSCN connection essential or is there a way of sending stuff from a non N3 app? Any pointers appreciated!

1 Like
#11

See: Message Exchange for Social Care and Health (MESH) - NHS Digital you can in theory use MESH from off N3, I’d apply (at the above link) and see where you get to.

1 Like