Stream: austria tc
Topic: Patient Profile .at
Harald Kornfeil (Mar 26 2017 at 21:28):
In the d-a-ch stream our german colleagues are busily discussing a patient profile for germany. What irritates me reading their posts, is that they are thinking about an identifier slice for their .de-spezific "gesetzlichekrankenversicherungsnummer", which is - as far as I understand it - basically the equivalent to the austrian "sozialversicherungsnummer".
I do not think that it is a reasonable approach when .de does a Slice for their gkv-number and we in .at do the same for our sv-number, since both of these are basically the same - both numbers are found in the same field at position 6 "Personal Identification Number" on the European Health Insurance card = EKVK/EHIC (as on the back of the ecard resp. eGK).
If every EU country does their own identifier slice, data exchange within the EU could get more complicated as necessary.
IMHO it might be a smarter approach if the EU-countries first line orientated on the fields/positions of the EKVK/EHIC (EHIC-Profile) - and then, second line everybody added national profiles/extensions/slices with their very specific national identifiers (e.g. in .at the ELGA/bPK).
So at least all the EU-countries would share a common patient profile.
for the fields/positions of the EKVK/EHIC see:
https://kvnummer.gkvnet.de/pubPages/krankenversichertennummer.aspx
https://de.wikipedia.org/wiki/E-card_(Chipkarte)
Reinhard Egelkraut (Mar 28 2017 at 17:20):
Hi @Harald Kornfeil ,
I assume you are talking about the following topic in the german (d-a-ch) stream (I am already watching this one very closely):
https://chat.fhir.org/#narrow/stream/german.20(d-a-ch)/topic/Patient.20Basisprofil
In my opinion to do this on an European level might become difficult (and time consuming) and the result could very well be that the common ground is the recommendation to use the patient resource as it is and do profiles on your own. Even if it's possible to create an European patient profile using the patient resource with slices for the identifiers of the EHIC, it might still be necessary to create additional profiles for the usage in Austria (and the other countries as well). In ELGA for example, it would be necessary to have extra slices on patient.identifier for the bPK-GH, the PID of a "ELGA Bereich" and maybe local patient ids - all of them not covered by the EHIC but vital for the communication with ELGA, resulting once again in an Austrian patient profile. If we would just need a social security number then you are right, aligning with the EHIC data set would be a good approach.
What could work better is sort of a "bottom-up" approach - when we have reached a conclusion on what's necessary to define an Austrian patient profile, the next step is to consolidate this with the members of the D-A-CH group, to figure out if we can agree on a common patient profile between 3 countries. And if that works and the profile is common enough, try to get in touch with HL7 Europe to raise it to an European profile.
@Alexander Mense , @Oliver Krauss , @Andreas Schuler - what's your opinion on this?
Karl Holzer (Mar 28 2017 at 17:47):
Hi @Harald Kornfeil , Hi @Reinhard Egelkraut
Additional to Reinhard's comment that means to cover the European and the Austrian case it would reasonable to create the European patient and letting the Austrian patient inherit from it with additional slices for the identifiers already listed by @Reinhard Egelkraut .
Maybe it would be another idea to propose common slices to be used in different national profiles without definition of a European patient? So we could come around the probably tough coordination on a European level.
Harald Kornfeil (Mar 28 2017 at 22:02):
If an EU patient with his EHIC comes to my practice I need to store his EHIC data to be able to send it to the local GKK for reimbursement. And I guess in the other EU countries they will have to do the same - So we would need to be able to store EHIC data anyway.
For an Austrian Patient I would just need to store his SVNR and id-code of his insurer (and wheter I have checked his ecard electronically and the "Scheinart" for reimbursement) but not the card-number and not the expiry date of the EHIC (whether the card is valid resp. whether the patient is insured is checked as part of the electronic ecard-check-process with the Hauptverband)
As I stated in my first post and as @Reinhard Egelkraut also pointed out - we need also some other ids for the Austrian patient for ELGA.
Creating an Austrian Patient that exists alongside to an EHIC dataset could create amiguity and confusion (there are now 2 places to store a svnr now - should we use one or the other or both? ;-) ).
What about an german EU-patient that comes to Austria- does an Austrian system need to use the german slice to store his gkvnr or should I store it in an EHIC dataset or just store it in the field for the Austrian "svnr" - since it is the same thing anyway - just for another country ... ;-) ????
Oliver Krauss (Mar 29 2017 at 07:51):
All compelling arguments really.
Looking at it from a technical point of view it would be good to have a common base profile. If a german patient visits an austrian practitioner this would still mean that there has to be a mapping between the german and austrian profiles though, since the german patient still adheres to his profile. The mapping would only be simpler.
Looking at it from a pragmatic or organizational point, our german colleagues have a need for a german profile NOW. Even if the HL7 Affiliates in the EU would start coordinating today the timeline until we get EU profiles, especially without local profiles to look at for reference, would look bleak. What Karl suggests with only defining common extensions/slices would still require a lot of coordination. But it would be much faster since agreeing on one single point is a lot faster than an entire profile.
All in all I am too a fan of the bottom-up approach since it A) shows, due to the existing profiles, that there is a need for consolidation on a higher level, B) gives everyone involved points of reference as to what the local requirements are and C) delivers technical solutions to everyone involved faster since the "EU-org-overhead" comes into play later. The downside is that local profiles will have to be adapted later, as the EU-profiles come into play.
We will see how that theory works out in practice when Austria-TC defines it's AustrianPatient and coordinates with the other affiliates in the DACH region on the Madrid WGM (and in the future as well!?). What is important right now is that we do something, and learn from it.
Reinhard Egelkraut (Apr 20 2017 at 14:55):
Hi,
@Harald Kornfeil , @Oliver Krauss , @Karl Holzer, @Alexander Mense - this week HL7 Austria received the ordered gotomeeting accounts. So I am going to set up a conference for our TC FHIR to discuss this topic further.
Reinhard Egelkraut (Jul 25 2017 at 10:27):
on the implementers stream there is currently a discussion going on which is somehow related to ours - how to model EHIC identifiers in FHIR, see also:
https://chat.fhir.org/#narrow/stream/implementers/topic/EU.20Patient.20Identifiers.20(EHIC.20and.20Driving.20Licence)
Last updated: Apr 12 2022 at 19:14 UTC
