In order to implement an FHIR based system for exchanging patient data, I would know if there is an ISO standard that could be applied to my project ?
I know that HL7 Version 3 is standardized with ISO/HL7 21731.
Is this the same thing for HL7 FHIR ? IE Would an FHIR based system be automatically ISO/HL7 21731 compliant ?
Thanks.
No, it's not the same thing. No, a FHIR based system would not automatically be 21731 compliant. FHIR has not yet been brought to ISO - it will be a number of years before it becomes time to do that
If all you're looking for is a tick in the box to meet legal requirements, you might get away with claiming that a FHIR based system is 21731 compliant
Related
I want to create an interoperability platform FHIR compliance with a complex business logic.
Our clients can send FHIR resources to platform.
The best architecture by best practise documentation is an ibrid system FHIR + SOA, as this link says.
Now I write two examples of scenario I must to manage:
The first:
I want to create a ServiceRequest resource with a subject where I know only the fiscal code as identifier. If I need other informations about the subject I can query an external database, for example, to know name, surname and others.
I can do this, send to my interoperability platform only a Service Request as follow?
"resourceType" : "ServiceRequest",
"subject" : {
"reference" : "Patient?identifier=FISCALCODE"
}
and so on
The second:
I want to create a ServiceRequest resource with a RelatedPerson linked in the requester tag.
The RelatedPerson is not a fully registry, I know only name and surname and a link to patient.
I must create a SOA method createServiceRequest where I must to pass two parameters the ServiceRequest and RelatedPerson? Or I can use a CRUD method for Bundle resource where I put as entries my ServiceRequest and my RelatedPerson?
So if I try to summarize, the possible ways are:
Create a method createMyMethodName(ServiceRequest serviceRequest, RelatedPerson relatedPerson)
Creation and exposure of this method is it FHIR standard?
If the answer of first quesiton point is YES, in my platform I'll have a lot of custom methods but I have a very strict control on the input informations
Use a CRUD Bundle method where I pass into the Bundle resource the following entries: ServiceRequest, RelatedPerson
In this way I expose only one method to write on my platform, but I must to implement a lot of code to manage all input bundles with several different entries (I suppose a mega switch and then for each branch I apply the business logic controls to accomplish my business logic rules)
This response is not intended as a complete response to your question and comes from a US perspective; however, you may find the perspective useful.
Gotcha with identifier queries
"reference" : "Patient?identifier=FISCALCODE"
As written, your ?identifier=FISCALCODE will query the FISCALCODE key against all code systems. I think what you want is to specify a code system, e.g. ?identifier=<CodeSystem>|<FiscalCode>
This is a common gotcha that's buried in the FHIR search documentation.
You'll either have to reference an existing code system, e.g. an Italy specific implementation guide analogous to US Core that contains the list of FiscalCodes, or author your own.
Which FHIR integration paradigm are you using?
Before diving into the createMethod vs Bundle question, I think it'd be useful to step back and pick an overall FHIR integration approach.
In my opinion, there are three major approaches:
Load data into an existing stand-alone FHIR server
Challenge: Drift between data loaded in FHIR server and other data warehouses
FHIR server queries non-FHIR API
Challenge: Duplication between FHIR API and non-FHIR API
NB: In the limiting case, there is no data stored in the FHIR server proper. Adding to the confusion, some will call this implementation a "FHIR gateway" instead of a "FHIR server."
FHIR server queries staging database for FHIR data
Challenge: Must write data access for each FHIR resource and each data element.
In the future, there may be a fourth approach where one uses the FHIR mapping language in real-time from an intermediate source model to multiple targets.
Your "CRUD Bundle method" is more in-line with POSTing data to a stand-alone FHIR server, whereas your "createMyMethodName" is more in-line with writing DAOs (Data Access Objects) to an external database.
In the limit where you don't need to maintain synchrony between the FHIR server and source data systems, importing data into a stand-alone FHIR server is much less work.
In the limit where you already have mappings to an intermediate data model (in the US, many large service providers will have mappings to either the USCDI or the Common Clinical Dataset), you'll have an easier lift writing CRUD in the FHIR server against an existing database.
For a more in-depth discussion, there was a FHIR integration patterns talk at FHIR Dev Days 2018, starting at Slide 21. Note that the author assumes a familiarity with architectural patterns such as the facade pattern.
Select a stand-alone server or library
Unless you have a compelling requirement or are a large company, it's advisable to use an existing open-source stand-alone server or library implementation. The three most popular are:
HAPI-FHIR (Java)
Microsoft (.NET)
IBM (Java)
If taking the stand-alone option, popular commercial FHIR servers
Microsoft (hosted in Azure)
Smile CDR (commercial version of HAPI-FHIR)
Firely Vonk
recently I've implemented MFN M15 message sender using HL7 (v2.x).
I see that HAPI FHIR is emerging as de-facto standard. Can someone point me out what would be MFN M15 message counterpart in https://hapifhir.io/?
NOTE:
I've already downloaded ca.uhn.hapi.fhir:org.hl7.fhir.dstu3:4.2.10-SNAPSHOT, and start investigation in org.hl7.fhir.dstu3.model but some directions would be more than gratefull.
Work on managing inventory using FHIR is still an area of exploration in FHIR (definitely a long way from 'de-facto standard' in this space, though FHIR is certainly becoming that for some areas of healthcare. In DSTU3, you may be able to cobble together part of a solution using Device and Medication. You might also look at this stream on chat.fhir.org: https://chat.fhir.org/#narrow/stream/179165-committers/topic/inventory.20tracking
I'm looking for a way to write notes into patient chart in Epic. Couldn't find any current FHIR specs about writing notes , but I didn't find this proposal http://wiki.hl7.org/index.php?title=ClinicalNote_FHIR_Resource_Proposal
Are there any other options ?
Great question. I work on the FHIR team at Epic and from a FHIR perspective we are having a similar problem identifying the appropriate place in FHIR to return notes. The proposal you have linked is a starting artifact in defining a new resource for that purpose. Until we determine in the FHIR community if a new spec should be created or an existing FHIR resource should be used, we do not have a FHIR specification to develop support against.
Outside of FHIR, today there are multiple ways to get notes into Epic such as HL7 v2, document based exchange, or something more Epic defined (these are just the ones I'm aware of). Without knowing more about your use case, it is hard to say what option may or may not meet your needs. I recommend you reach out through the contact us at https://open.epic.com/. From this email group they can dive into what integrations would meet your specific scenario and you will have input from a full gamut of integration experts.
And if you are interested in the standards side of things and getting notes in the FHIR specification, I'd encourage you to get involved on chat.fhir.org or any of the HL7 FHIR meetings to provide input on the specification!
*Edited to point to website instead of email.
This question already has answers here:
How to convert HL7 v2.x message to FHIR JSON?
(4 answers)
Closed 8 months ago.
Currently we are doing some POC around converting HL7 v2 message to a FHIR resource.
So as a first step we are converting the HL7 v2 message into an XML format using XMLParser from HAPI API, and as a second step we have written an XSLT to convert this XML into FHIR Resource XML format.
So I just wanted to figure out whether there is any simpler approach to do this HL7 v2 to FHIR resource conversion as a one step process rather than the two steps that I just spoke about.
There's no canned process. The core problem is that segments are not naturally identified, and resources must be (that's the core of the RESTful part). And identifying segments usefully is a business problem - it must be done based on the contents of the segment, it's context in the message, and local identification etc practices applicable to the source of the message
So what this means is that there's no canned code. I've published some javascript that works in a particular environment, but is useful as an illustration:
http://www.healthintersections.com.au/A31ToPerson.js
There's also http://bit.ly/14rgaWS
One of the best tutorials that I found about this topic is: HL7 v2 to FHIR Interface Mapping, from the author "Abigail Watson".
Assuming you will use the HAPI TestPanel as the HL7-v2.x EHR, that will be sent to the NEXTGEN CONNECT INTEGRATION ENGINE that makes the conversion from HL7-v2 to JSON, and then is sendt to the Meteor on FHIR Interface Engine.
Additional information about mappings can be found on the manual of the NEXTGEN(Or "MIRTH" the old name.) HL7 v2.x to FHIR Conversions.
While trying to understand how an existing system will map to FHIR resources, I am stuck in the documentation on Treatment/Care Preferences like the ones outlined here: http://wiki.hl7.org/index.php?title=Care_Preference
Would these preferences be handled in a list of extended objects? Or will FHIR be implementing a CarePreference resource?
This isn't catered for in the current set of resources. I guess you use Other (http://hl7.org/implement/standards/fhir/other.htm). It does seem like the kind of thing we'd want to define a resource for, but I'm not aware of any plans for one right now. I forwarded the suggestion along to the appropriate team.
btw, I'm not sure this question meets Stack Overflows guidelines - it might get edited/closed.
"Other" is the solution for now. Speed of the development of a specific resource is likely to be dependent on the number asking for it and the detail of the use-cases they supply. Consider sharing these on the FHIR list server. Alerts might be another mechanism to flag important preferences.