Reporting of patient with administrative CPR number

[RasmusThernoe]

When reporting the record target there is a choice between three templates:

• 1.2.208.176.7.1.10.106 (=Official CPR number)
• 1.2.208.176.7.1.10.107 (=Alternative identified, e.g. erstatnings CPR)
• 1.2.208.176.7.1.10.133 (=Administrative CPR number)

First question Is this the correct mapping between type of CPR number and use of template?

Second question When reporting an administrative CPR number the template (1.10.133) is in status 'Draft':

Is there a reason for the template to be in status 'Draft'?

Third question When reporting an administrative CPR number what must be stated in template 1.2.208.176.7.1.10.132 as 'id' attribute?

[TueCN]

1. Not entirely

   1. 1.2.208.176.7.1.10.106 is for CPR numbers issued by CPR-administrationen (I believe this includes "administrative" cpr numbers)
   2. 1.2.208.176.7.1.10.107 is for ALL other IDs, including the unofficial 'erstatnings cpr' IDs that each region generates independently. See #210 on how to generate a root for 'erstatnings cpr' for a specific region.
   3. 1.2.208.176.7.1.10.133 is a template that makes it possible to provide both a 1.2.208.176.7.1.10.106 ID and multiple 1.2.208.176.7.1.10.107 IDs

2. There is no significant difference between status 'Draft' and 'Active'. We may update the status of the relevant templates, but in general you should always use the newest version of a template (Draft or Active)

3. 1.2.208.176.7.1.10.133 must contain exactly one CPR-number and at least one alternative ID

[RasmusThernoe]

Thank you for a fast reply.

According to the reporting guide at page 32:

administrativt CPR-nummer • administreres af CPR • personnavn kan slås op i CPR • administrative CPR-numre tildeles af SKAT til personer, der ikke har haft adresse i DK, men som har skatteforhold, der relaterer sig til DK. • sådanne personer har derfor ingen dansk adresse, men stedfæstes ved en landekode, som skal indberettes sammen med patient-ID, da landekoden ikke i alle tilfælde kan slås op i form af en officiel myndighedskode i CPR.

If 1.2.208.176.7.1.10.106 is used for administrative CPR numbers how is the country code stated?

[TueCN]

Hmm, you could use 1.2.208.176.7.1.10.133 then. You should then specify the administrative CPR-number in an ID with root 1.2.208.176.1.2 and an alternative ID (that you generate yourself, using your own namespace) and then you can specify the address in a hl7:addr element.

However, hl7:addr requires that the country is an official myndighedskode in CPR

The value of country shall be drawn from value set: 1.2.208.176.1.2.3 CPR Country Identifiers

This makes it impossible to specify a country code that is not in CPR myndighedsregistret, which your quoted text indicates can happen.

I will raise the issue with SDS.

[RasmusThernoe]

”Logisk datamodel og indberetningsregler – Bilag 1” version 1.2 page 17:

01.102	01-01-2018	Patient.id IN {cpr.administrativ}	Patient.navn == Null AND Bopael.landekode IN MYNKOD{5100-5779; 5902; 5999} AND Bopael.kommunekode == Null AND Bopael.adresselinje == Null	Kendt patient tildelt et administrativt cpr-nummer indberettes med landekode.   Personnavn kan slås op i CPR.   Administrative CPR-numre bliver tildelt af SKAT til personer, der aldrig har haft adresse i DK, men som har skatteforhold, der relaterer sig til DK.   Sådanne personer har derfor ingen dansk adresse, men stedfæstes ved en landekode, som skal indberettes sammen med patient-ID, da landekoden ikke i alle tilfælde kan slås op som officiel myndighedskode i CPR.

How can I avoid violating this business rule 01.102 when reporting an administrative CPR number?

Will your suggestion above - using 1.2.208.176.7.1.10.133 - adhere to the business rule?

[RasmusThernoe]

This is blocking for our test

Do you have a list of administrative CPR numbers on your test environment?

We would like to trigger the business rule mentioned above and then verify that our reporting of administrative CPR numbers works correctly.

[RasmusThernoe]

We have followed the instructions you gave above - using template 1.2.208.176.7.1.10.133.

Are we reporting administrative CPR numbers in the correct way?

Request: eoc-acpr-create.zip

Response is succesful.

The result in the LPR3 administration client:

CPR number is displayed twice.

The country code is not displayed.

[TueCN]

The CPR number is displayed twice since there are 2 IDs in the message (one official and one alternative). This is expected. If your message contained 5 IDs, there would be 5 IDs on the UI. For the alternative ID you could generate a random UUID and use as extension instead of reusing 2611811225, to avoid confusion.

I think the address reported should have been displayed. I need to look into that.

Whether the approach in general is correct, I do not know yet. It depends on if administrative CPR numbers should be reported with a country code or not.

If country code is to be reported, the approach only works as long as you use country codes that exists in the Myndighedsregister. See rule 01.A in Logisk datamodel og indberetningsregler - Bilag 1 (PDF)

-> landekode | MynKod {5100-5779; 5902; 5999} | gyldig landekode iht. Myndighedsregisteret

The question is whether indberetningsvejledningen actually states that it should be possible to report country codes NOT in Myndighedsregistret. This is not currently possible.

sådanne personer har derfor ingen dansk adresse, men stedfæstes ved en landekode, som skal indberettes sammen med patient-ID, da landekoden ikke i alle tilfælde kan slås op i form af en officiel myndighedskode i CPR.

[RasmusThernoe]

OK - awaiting the answer.

After having tried the "1.2.208.176.7.1.10.133 approach" my presumption was that it did not fit the purpose because:

1. Alternative ID is mandatory in 1.2.208.176.7.1.10.133. This results in either: The CPR number must be reported twice in the CDA document and is displayed twice in the LPR3 client or a random alternative id have to be made up be the reporters which will just be noise in the reporters code and in the LPR3 client.

2. Country codes does not seem to be supported when using 1.2.208.176.7.1.10.133 - at least not in the LPR3 client.

3. Country codes not in myndighedsregisteret not possible to report.

4. Administrative gender is mandatory in 1.2.208.176.7.1.10.133 but there is not reason for this since gender is known to the CPR registry.

[TueCN]

I have investigated your questions and received clarification on the wording of the text in Indberetningsvejledning:

1. Alternative ID is mandatory yes, but 1.2.208.176.7.1.10.133 is the only way to include both an official CPR-number and a country code in a submission. If the accompanying noise is unacceptable, please file an enhancement request with SDS

2. Country code and other address-related information in the submission is not currently registered when using template 1.2.208.176.7.1.10.133. This is a bug and will be fixed.

3. Country codes not in Myndighedsregisteret should not be reportable. This means that the current functionality is correct. See clarification from SDS (in Danish):

   Ifølge SDS’s oplysninger kan man ikke være sikker på, at landekode altid er angivet i CPR-registeret, når der er oprettet administrative CPR-numre. Derfor har det været nødvendigt at kravstille i indberetningsvejledningen, at landekoden indberettes til LPR3. Hvis ikke landekoden indberettes til LPR3, og den heller ikke er angivet i CPR, vil det ikke være muligt at afgøre, hvilket land patienten tilhører.

   Med sætningen ”sådanne personer har derfor ingen dansk adresse, men stedfæstes ved en landekode, som skal indberettes sammen med patient-ID, da landekoden ikke i alle tilfælde kan slås op i form af en officiel myndighedskode i CPR.” menes altså, at landekoden ikke i alle tilfælde findes i CPR og derfor ikke kan hentes i CPR med afsæt i det administrative CPR-nummer.

4. Administrative gender is mandatory in 1.2.208.176.7.1.10.133, yes, but the gender can be determined from the CPR-number alone, when creating the submission. If this is unacceptable overhead, please file an enhancement request with SDS

[RasmusThernoe]

Ad 1) Do reporters have to remember the alternative ID or can a new one be create in each request?

• E.g. what if EOC is reported on a patient with alternative id A and ENC is reported on a patient with alternative id B. Will this be fine and not interpreted as mixed data from different patients under the same EOC?

• E.g. what if EOC is created in version 1 on patient with alternative id A and then EOC is updated in version 2 on patient with alternative id B. Will this be fine and not interpreted as "no EOC on that patient" during the update?

[TueCN]

No, reporters do not have to remember alternative IDs. One can be generated for each request.

Note that EoCs not directly contained in the submission will not have their patient information updated. In other words: It is only the EoCs in a DK Episodes Of Care Section of the submission that use the patient information from the submission.

• Yes this will be fine. The new ENC will belong to some EoC, and it is the patient information of that EoC that is relevant to the ENC.

• Yes this will be fine. The updated EOC will belong to id B. The EoC will no longer be associated with id A.

Since all CDA documents in the same CDA set must be associated with the same person, LPR views the change in ID not as a change in person, but purely as a change in id of that person. [I am not sure this is actually correct, will need to investigate]

[RasmusThernoe]

Since all CDA documents in the same CDA set must be associated with the same person, LPR views the change in ID not as a change in person, but purely as a change in id of that person. [I am not sure this is actually correct, will need to investigate]

I am a bit confused by your answer above: Are your answers final or do you need to do further investigation?

[TueCN]

I need to do further investigations (the strikethrough signified the edit of my post). I will get back to you in the new year.

Merry Christmas and happy New Year :)

[RasmusThernoe]

Any news on how to report an adminstrative CPR number with a country code?

[jonigkeit]

RESOLUTION We are updating/extending the templates for DK Civil Registration System Identified Patient Role to include addr elements for administrative cpr numbers. We have also relaxed the cardinality on patient from DK Civil Registration System And Alternatively Identified Patient Role as the information can be extracted from the CPR identifier. As with Civil Registration System Identified Patient Role you specify addresses of administrative cpr number in the addr element.

[RasmusThernoe]

Will you disable the business rule 01.102 - mentioned earlier in this thread - until reporters have had a chance to implement and test this extension to the LPR3 service?

Would very much like the users not to be prompted by the business error when fetching the accumulated error list.

[TueCN]

The service cannot determine whether a CPR-number is administrative or not. Therefore, rule 01.102 is not implemented as a validation rule in the service, so you should never get this error in any response from the web service.

[RasmusThernoe]

Where are the validation rules implemented in the LPR3 service documented?

Since not all validation rules in the reporting guide (Appendix 1 and 1a) are enforced by the service.

[TueCN]

Even though some validation rules described by indberetningsvejledningen are not strictly enforced by the service, you should still strive to uphold them.

The strictly enforced rules can be found here:

• SCHEMATRON: http://lpr-art-decor.westeurope.cloudapp.azure.com:8080/art-decor/decor-templates--lpr-?section=templates
• INTEGRITY_CHECK https://scandihealth.github.io/lpr3-docs/aspects/index.html#data-integrity-rules
• BUSINESS_RULE (rules from Logisk datamodel og indberetningsregler - Bilag 1 and Resultatindberetningsspecifikationer (RI-specs) - Bilag 1a https://scandihealth.github.io/lpr3-docs/testenvironment/index.html#rules-implemented-on-test-system

[TueCN]

Closing due to inactivity, as the bugfix was deployed 9th of January.

Feel free to request the issue be reopened by leaving a comment.