I’m working on conversion from/to HL7 v2 to FHIR.
Following v2 to FHIR conversion guidelines Message OML_O21 to Bundle Map - HL7 Version 2 to FHIR v1.0.0
We are getting these resources which don’t appear to be supported by GOMS.
- Encounter from PV1 conversion
- DocumentReference from OBX (type ED)
- Binary from OBX (type ED) when PDF, not required for plain/text formats.
Re last comment. I don’t think we want to include large attachments as base64 in DiagnosticReport.presentedForm (or equivalent in DocumentReference). Our sample genomics report is 7k in size and believe it would better to separate this out.
In addition we have questions around codes used in DiagnosticReport.code.
This is due to the presence of OBX (type = ED), we are currently saying this maps to DocumentReference.code (probably following Scottish SNOMED coding) → this matches the code used for DiagnosticReport.code in the GOMS IG.
However we probably have a second code coming from OBR - if we follow DHCW (Wales) this would be a procedure code (v2 and FHIR). If we followed Yorkshire and Humberside this would also be a procedure code InterweaveDiagnosticReport - Interweave Implementation Guide v0.1.0.
So for both this makes lean towards including procedure code in our DiagnosticReport but where?
Hi Kevin,
Encounter was not raised as one of the required data items (in consultation with the clinical SMEs) and has therefore not been modelled. For genomic orders, I expect this information will need to be stripped out/ignored.
For DocumentReferences/binary attachments, we support both base64 encoded attachments as well as links to documents. While not explictly mentioned in the models, these can be attached as DiagnosticReports, DocumentReferences or Media resources (in the case of images).
Regarding SNOMED encoding of previous clinical/(histo)pathology reports, we will support any valid coding provided, though will take the approach agreed by the domain from which the report originates, e.g. for Pathology: Pathology FHIR Implementation Guide (this also specifies a report code within DiagnosticReport.code.
For Genomic Reports, we expect to align with the international GenomicReporting IG guidance: Genomic Report - Genomics Reporting Implementation Guide v3.0.0.
Regarding where to place the procedure code, the backport of CodeableReference datatype for the basedOn field makes the most sense (given that the report may be based upon a procedure and is not the procedure itself). We will liaise with the UK Core team for further guidance on this.
Best,
Omar
How do I raise a request a request to get Encounter added?
It is a fundamental concept within existing enterprise domain models and already exists in both IHE and HL7 around ordering and reports.
Re: attachments can we have an option to remove presentedForm.data from https://digital.nhs.uk/developer/api-catalogue/genomic-order-management-service-fhir#get-/FHIR/R4/DiagnosticReport
including base64 data may lead to large amounts of data being returned from searches (where we are not interested in the pdf contents)
Hi Kevin,
I’ve passed on your request to the MDS team for consideration, they will be in touch separately.
Regarding DiagnosticReport.presentedForm, we’ll investigate and get back to you.
Many thanks,
Omar
Also FYI, I’m going to suggest we start supporting the IHE XD-LAB Document Entry metadata model now as we are seeing this around v2 interactions and so our FHIR model.
Elaboration of the IHE MHD/XDS and FHIR version of this is here DocumentReference - North West Genomics Testing Workflow (GTW) v0.0.1
As a interim solution to replace CDA, will suggest using PDF instead and this allows a swap to FHIR Document (EU Lab Report?) at a later date.
If feasible we can provide NHS England (and other regions) a HIE interface roughly along these lines HIE-Whitepaper
Re: Encounter.
I think we will regard this a difference from the established model.
This also applies to extension FHIR Genomics Implementation Guide
Most of this we will have in Encounter.participant and so we probably won’t support this extension.
We probably view this as asking the model not to be changed from NHS England HL7 v2 Specification documentation around PV1 segment and so as FHIR
@Kevin_Mayfield, regarding encounter, this is being looked into by the MDS team, however, within the OML_O21 message we are looking to as the equivalent of the test request, the PV1 segment is optional (and there has currently been no need identified from the clinical SMEs to record information which would be housed in this segment).
In cascade testing scenarios, where testing for an individual is determined through prior genomic testing on another individual, there will be no encounter serving as the trigger for a test.
Regarding the additional contact extension, this is not related to a patient encounter but is rather a practitioner that should be contacted if questions regarding the order arise (if they are different from the responsible clinician). This would be mapped from the CTD segment attached to an ORC, rather than a PV1.
Regarding document metadata, this has not been elaborated fully within the Order Management project (as only the required data at test order entry has gone through discovery), however, we are currently working on alignment to EU Lab report, and will investigate the IHE XD-LAB/MHD/XDS standards for alignment.
Best,
Omar
We probably need to talk about this, the act of recording clinical information (order or report) should result in an Encounter/PV1.
Our initial proposal for the HL7 v2 side is to follow DHCW + elements from NHS Englands ADT standard - so PV1 will be mandatory, and apply the same rules and data model in HL7 FHIR.
Hi Kevin, yes, PV1 is required for an ADT message. However, to my knowledge there is no such requirement on a lab order (OBR/OML/ORM etc.). The PaLM framework also specifies for a LAB-1 that the PV1 may be empty and on UK Core FHIR, there is no profiling to indicate ServiceRequest is required. Could you please point me to the standards you mention indicating PV1/Encounter is mandatory for lab orders?
Another scenario where they may be no encounter is in the case of testing of a sample from the deceased, e.g. to understand family history of a disease.
While it may be useful for a local EPR to record the triggering encounter for a test, if this is not used by other systems fulfilling the test order (as indicated by it not being raised during the data set discovery work), we should be questioning whether there is any value in including it in GOMS messages.
Happy to take this offline for discussion.
The Yorkshire description is best summary of why it is important InterweaveEncounter - Interweave Implementation Guide v0.1.0
Most of the systems (EPR) in our region appear to populate encounter in both ServiceRequest and Diagnostic. So if we swapped from sending you the data to providing API access, having encounter references/identifiers would become very important. This also appears to be true for XDS systems.
Wales/DHCW have it as mandatory in its ORU spec - can probably send a copy over if required. They don’t have a FHIR standard for this.
Yes it may not be mandatory but neither should it not be supported - it is good practice to support it.
That I can understand. Our general consensus is that we will not be limiting what information entities are able to submit. Under the hood, the broker uses a standard HAPI server which should support all resource types. I can feed back to the broker team that we do not restrict the resource types supported (though to maintain a deliverable scope will only likely be providing guidance on those resources which have been deemed essential to order management and fulfilment)
I’ve had another look at this. From a domain modelling (e.g. Domain Driven Design) perspective:
Encounter comes out as SHALL/SHOULD reference to Correlation/Business Identifier (Correlation Identifier - Enterprise Integration Patterns) which is probably the Order Placers Visit Number and so in FHIR an Identifier with VN (and v2 PV1-19 Visit Number).
The resource/source for this should belong in another domain such as ‘Health Information Exchange’ such as YHCR use case or Patient Administration Management.
So in theory no resource, just a SHALL/SHOULD encounter identifier reference in ServiceRequest and DiagnosticReport. E.g. from our ServiceRequest
This is inline with US Core guidance for both resources and compatible with NHS England V2 Messaging IG, is no guidance in UK Core around this.
1 Like
Regarding reports - as Omar mentioned we can support both references and attachments, we are investigating any maximum sizes for attachments, generally reports are quite small so it may be feasible to include them as attachments. Interesting that your preference is to separate out a 7k report.
Once we have some guidance we will update the community.
1 Like
In our region we have a number of EPR’s with FHIR API’s and EDMS with XDS API’s.
When I checked those EPR’s FHIR API spec’s they all had references (probably this is a US requirement).
Ideally I don’t want to do transforms inside FHIR (regional to/from national).
I’d prefer a simple rule such as:
HL7 v2 OBX (type = ED) = FHIR DocumentReference + Binary = XDS Document Entry + file.
This makes any transforms less complicated.
DiagnosticReport.presentedForm.data isn’t used (for PDF).
So if you move to EU Laboratory Report. The Binary in FHIR becomes a FHIR Bundle (and this also matches how it would be done in XDS … and would be supported in v2)
Hi Kevin, we are using DocumentReference for all document types apart from actual reports, this is to support the move to structured reporting in the future, whereby the PDF report will also have associated structured content which could be captured within a DiagnosticReport. This is consistent with the FHIR representation of a report in Genomics.
While the report itself may be unstructured, some metadata can be captured within a DiagnosticReport, which is not present in DocumentReference, but would still be useful for retrieval/analysis purposes, e.g. resultsInterpreter, specimen and conclusion.
For boundaries between DiagnosticReport and DocumentReference, please see:
DiagnosticReport - FHIR v6.0.0-ballot2 and
[FHIR-19249] Boundary clarification for DiagnosticReport (vs DocumentReference) - Jira
EU Lab report also uses DiagnosticReport as the primary entity in the document bundle.
However, I do get your point regarding DocumentReference and XDS equivalents, in future phases we will look to integrate with the National Document Repository (an XDS style service) and only record the link to the NDR resource within the genomic order management service.
