Pre-adopt van Address Type BI (Billing)
Return to InM V2 voorstellen
- meeting: TC-InM
- Author: Alexander Henket
- Status: CLOSED
Contents
Inleiding
verzoek van TC-AM (20-10-2009)
Binnen de TC-AM hebben we een use case om het Billing address van een patiënt naast het Mailling address door te geven. In versie 2.4 is hiervoor geen geschikte Address Type, maar in versie 2.6 wel. Wij zouden als TC-AM deze Address Type graag pre-adopten in 2.4, maar omdat deze tabel onderdeel is van H2, is die beslissing aan de TC-IM. Graag jullie uitspraak hierover.
Mocht jullie uitspraak positief zijn, dan zouden we zelfs graag nog deze update willen meenemen in de publicatie van de geballotte hoofdstukken 2, 3 en 6.
Use case
De use-case in het UMCG is dat er een onderscheidend adres voor financiële correspondentie nodig is, anders dan het generieke postadres. Zolang dit verschil niet gemaakt kan worden zou alle post naar het postadres gestuurd moeten worden. In het patiëntregistratiesysteem (PATREG) in het UMCG kunnen twee verschillende adressen van een patiënt worden vastgelegd, namelijk het huisadres en het financieel correspondentie-adres. Er is geen overeenkomstige waarde in de HL7 Table 0190 – Address type. Address type ‘M’ is niet geschikt omdat dat een adres is waar alle post heen zou gaan (dus ook de niet-financiële post).
Huidige tabel in de HL7 2.4 Internationale en NL implementatiehandleiding
2.9.1.7 Address type (ID)
Type is optional and defined by HL7 Table 0190 - Address type.
| Code | Omschrijving |
|---|---|
| BA | Bad address |
| N | Birth (nee) (birth address, not otherwise specified) |
| BDL | Birth delivery location (address where birth occurred) |
| F | Country Of Origin |
| C | Current Or Temporary |
| B | Firm/Business |
| H | Home |
| L | Legal Address |
| M | Mailing |
| O | Office |
| P | Permanent |
| RH | Registry home. Refers to the information system, typically managed by a public health agency, that stores patient information such as immunization histories or cancer data, regardless of where the patient obtains services. |
| BR | Residence at birth (home address at time of birth) |
Voorstel
Grijs maken (=vet op wiki)van alle codes uit tabel 0200 - Name Type welke worden gebruikt.
| Code | Omschrijving |
|---|---|
| BA | Bad address |
| BI | Factuuradres (Billing address), pre-adopt van v2.6 |
| N | Geboorteplaats (Birth, née, birth address not otherwise specified) |
| BDL | Birth delivery location (address where birth occurred) |
| F | Country Of Origin |
| C | Current Or Temporary |
| B | Zakelijk (Firm/Business) |
| H | Privé (Home) |
| L | Legal Address |
| M | Postadres (Mailing) |
| O | Office |
| P | Permanent |
| RH | Registry home. Refers to the information system, typically managed by a public health agency, that stores patient information such as immunization histories or cancer data, regardless of where the patient obtains services. |
| BR | Residence at birth (home address at time of birth) |
Discussie
Discussie sluit vrijdag 4 december (was) 27 november 17:00 uur
- Irma: volgens mij gaat het juist niet om een afwijkende betaler, maar juist om het vaste adres voor patient voor financiele correspondentie. En het is ook niet gerelateerd aan waar de patient is verzekerd, dus daarom niet in IN1. Nota's die naar de verzekering toe gaan, gaan naar het adres van de verzekering. Nota's en aanmaningen die naar de patient gaan moeten naar het gevraagde adrestype. Tav interpretatie: Billing Address lijkt mij niet voor meerdere uitleggen vatbaar.
- Rene: (vraag) waarom kan IN1-19 niet voor deze use-case? Of desnoods GT1-5 ? Frank gebruikte de bewoording "afwijkende betaler" - dan is de use-case niet over een billing adress van de patient, maar over een adres van een andere partij. De use-case doet geen uitsluitsel of het gaat om een adres *van de patient zelf* of van een *afwijkende derde partij*.
- De documentatie van BI is nogal minimaal. Wat verstaat men daar internationaal precies onder?
- Alexander: het adrestype "BI" is bedoeld om aan te duiden dat het betreffende adres moet worden gelezen voor gebruik in financiële context. De volgende vraag is in welke context het adres zelf moet worden gezien. Het antwoord daarop is: dat hangt ervan af in welk segment het wordt gebruikt. In het ROL-segment heeft een adres met type "BI", de betekenis "Financieel adres voor de persoon in dat ROL-segment". In het PID-segment heeft een adres met type "BI", de betekenis "Financieel adres voor de patiënt in het PID-segment". Dit houdt in elk geval in dat ongeacht in welk segment je een financieel adres ook kwijt wilt, het juiste adrestype ("BI") op dit moment in versie 2.4 ontbreekt. De use case van Frank is In het patiëntregistratiesysteem (PATREG) in het UMCG kunnen twee verschillende adressen van een patiënt worden vastgelegd, namelijk het huisadres en het financieel correspondentie-adres: ongeacht of het adres nu in hoofdstuk 3 (PID) of 6 (IN*) wordt toegepast heb je daarbij behoefte aan adrestype "BI".
- Irma: ik ben voor pre-adopten van BI.
- Rene: (nav uitleg Alexander): ik ben zeker niet tegen de pre-adopt van BI. Maar ik zou wel graag bij de documentatie van BI zien dat er uitleg wordt gegeven wanneer je BI gebruikt in PID (financieel adres van de patient zelf) versus adres van afwijkende betaler (in een ander segment, niet in PID). Indien men een dergelijke implementatievoetnoot plaatst dan heb ik geen enkel probleem met het toevoegen van BI aan de tabel. Rene spronk 20:50, 18 November 2009 (UTC)
- Alexander: ongeacht waar het adres verder wordt gebruikt (PID, GT1, IN1, etc., zulks nog ter verdere uitwerking door TC-AM) moet het adrestype er überhaupt wel zijn anders hebben we ook verder geen reden om erover door te praten in deze TC. Voor TC-IM zou het voldoende moeten zijn dat er een legitieme use case is voor dit adrestype, om toevoeging ervan door te voeren in de betreffende tabel . Er is m.i. geen afhankelijkheid van TC-AM's verdere uitwerking. Ik nodig geïnteresseerden uiteraard van harte uit de discussie over de uitwerking verder in TC-AM te voeren.
- Rene: formeel mag je daarin gelijk hebben; maar de volgordelijkheid is dan niet de juiste. AM moet eerst uitwerken wat de use-cases zijn. En zou de oplossing daarvoor zijn dat je een addres in GT1 opneemt, dat is een BI adrestype overbodig omdat de context dat al impliceert. Internationaal is het gebruikelijk een voorstel te onderbouwen met de diverse opties die er zijn iets op te lossen, en waarom die bedachte oplossingen al dan niet acceptabel zijn. Dat onderbouwde voorstel ligt niet ter tafel.. wellicht dat het niet veel werk is, maar het is iets wat wel even gedaan moet worden. 1 van de opties tou een BI adres zijn; wellicht is dat de enige optie die redelijk is, maar dat is niet aangetoond. Een pre-adopt doen we nooit zomaar, daar moet een goede reden voor zijn, met motivatie.
- Alexander: na behandeling in TC-AM 2010-01-13
- use case 1: een administratiekantoor dat de betalingen verder afhandelt, maar geen financiële eindverantwoordelijkheid overneemt van de patiënt.
- use case 2: studenten die veel verhuizen en om te voorkomen dat de betalingen niet worden gezin/afgehandeld, afspreken dat de ouders de nota's moeten ontvangen, terwijl bijvoorbeeld afspraken wel direct aan hen worden gestuurd.
- in de use case van het UMCG gaat het dus expliciet om een adres voor financiële correspondentie waarbij de persoon/organisatie achter dat adres niet de verantwoordelijkheid voor betaling overneemt van de patiënt. Daarmee valt gebruik van het GT1-segment af welke is bedoeld voor personen/organisaties die garant staan voor betaling. Ook IN1-19 valt af omdat dit veld is bedoeld voor het Adres van de (hoofd-)verzekerde, indien dit niet de patiënt zelf is.
De TC-AM heeft dus als enige mogelijkheid voor deze use cases geïdentificeerd dat er gebruik moet worden worden gemaakt van het reguliere veld PID-11 Patient Address. Om daar de adressen van elkaar te kunnen onderscheiden, is de aanvullende code BI in tabel 0190 Address Type noodzakelijk en de TC-AM vraagt de TC-InM dan ook deze op te nemen.
In de omschrijving van een code in een codetabel is het niet gebruikelijk of zelfs wenselijk om context te gaan beschrijven met betrekking tot de toepassing. De code moet een betekenis hebben, maar in welke context die betekenis wordt gebruikt hoort thuis in de bericht/segment/veldbeschrijvingen. --[User:Alexander Henket|Alexander Henket] 10:34, 13 January 2010 (UTC)
- Wiggert , use case duidelijk echter waarvoor wordt dit adres dan gebruikt, om de factuur naar de jusite persoon te sturen. M.a.w. dadelijke hebben we een drietal adressen vastgelegd en ius het niet duidelijk welk adres waarvoor gebuikt moet worden, volgens mij vallen de use cases nog steeds onder de categorie "afwijkende betalers"
Alexander schrijft: in de use case van het UMCG gaat het dus expliciet om een adres voor financiële correspondentie waarbij de persoon/organisatie achter dat adres niet de verantwoordelijkheid voor betaling overneemt van de patiënt. Hoe gaan je dan om met aanmaningen naar welke adres moet je b.v. de aanmaning sturen ? Mijn advies: keep it simpel dadelijk is er een keuze uit meerdere adressen en is het niet duidelijk welke adres in welke context gebruikt moet worden.
- Rene: Gegeven de use-cases die Alexander hierboven aanhaalt is er, vanuit IM gezien, een redelijke use-case voor de pre-adopt van BI als adres type. Alexander heeft gelijk dat in de tabel 'adrestypen' een contextuele uitleg van BI versus GT1/IN1 niet op zijn plaats is; maar persoonlijk zou ik wel graag zien dat dit dan (contextueel) wordt opgenomen in Hoofdstuk 3 (bij PID-adres veld) en in Hoofdstuk 6 (bij Guarantor-Adres, en IN1-adres). Als wij er -als HL7 kenners- al lang over discussieren, dan behoeft het nadere documentatie IMHO.
- Alexander: acties (nog te publiceren):
- Hoofdstuk 3, PID-3, Tabel 0190 Address Type aangevuld met BI "Adres voor financiële correspondentie en waarbij de persoon/organisatie achter dat adres niet de verantwoordelijkheid voor betaling overneemt van de patiënt. Alleen gebruiken indien afwijkend van het postadres (‘M’)"
- Hoofdstuk 6, GT1 segmentbeschrijving aangevuld met Merk op dat een afwijkend patiëntadres voor financiële correspondentie, waarbij de ontvanger niet garant staat voor de betaling, wordt doorgegeven in PID-11 Patient Address.
- Hoofdstuk 6, IN1-19 Insured Address en GT1-5 Guarantor Address aangevuld met:
Er mogen meerdere adressen in dit veld worden geplaatst. Het eerste adres moet het postadres zijn (‘M’). Indien het postadres niet wordt doorgegeven, blijft de eerste herhaling van het veld leeg. Andere adrestypen (zie HL7-tabel 0190 - Address Type) komen in de tweede en volgende herhalingen van het veld..
Tevens tabel 0190 toegevoeg met daarin BI en de volgende omschrijving: Financieel correspondentieadres (Billing). Alleen gebruiken indien afwijkend van het postadres (‘M’)
Voorstel tbv stemmen
Toevoegen (pre-adopt) van de code BI - Factuuradres (Billing address), pre-adopt van v2.6, aan HL7 tabel 0190 Address Type.
Gegeven de use-cases die Alexander hierboven aanhaalt is er, vanuit IM gezien, een redelijke use-case voor de pre-adopt van BI als adres type. Alexander heeft gelijk dat in de tabel 'adrestypen' een contextuele uitleg van BI versus GT1/IN1 niet op zijn plaats is; maar InM zou wel graag zien dat dit dan (contextueel) wordt opgenomen in Hoofdstuk 3 (bij PID-adres veld) en in Hoofdstuk 6 (bij Guarantor-Adres, en IN1-adres).
Stemuitslag
Resultaat stemmen: voor, tegen, onthouding (5-0-2).
Het voorstel is aangenomen
