# entry[].resource.description
HpiPractitioner.qualification.code is 1..1  making it mandatory. We have many people on the HPI with qualifications gained at overseas universities, I don't think we can have codeable concept for  all qualifications. Even NZ universities and tertiary institutions  quals would be a challenge. We would need a codeset not just for todays degrees/quals but those in the past as well.

# entry[].resource.note[].text
We can add an 'unknown' code at the moment. But I'll see if I can find out why it is required...

# entry[].resource.note[].text
And an even tidier solution is to just have the text component of the CodeableConcept...

# entry[].resource.description
Current HPI has the year the qualification was gained. Would  the period be used for this. Many quals would have a period  but without an enddate.

# entry[].resource.description
Issuer is a reference to Organisation,  We could put the Ministry of Education for NCEA qualifications and the NZ Universities, but there are also all the Polytechnics and other training institutions, its a case of where do you stop and do these organisations lie within our current definition of "organisation is a group of people providing healthcare or healthcare related services" . And then what about all the overseas qualifications, we would still want to capture the name of the institution as text, not as reference organisation

# entry[].resource.note[].text
One solution is to make the Organization a contained resource, and then just use the Organization.name property.

# entry[].resource.description
This  'notes' field should be  under the registration not the qualification.

# entry[].resource.description
Is this the HPI orgId of the RA or professional body issuing/assigning membership/APC ie the assigning organisation in the current HPI

# entry[].resource.note[].text
Well, the identifier has a 'system' which is the namespace of the identifier value and described by the NamingSystem resource. Adding a separate 'registrationAuthority' element  (ref -> Organization) would make the link to the RA explicit...

# entry[].resource.description
Current HPI also has a supplying organisation ID for a registration. It is usually the same as the assigning org but also caters for when a different org is administering the RA supply to HPI,  

Current HPI  has a code in addition to the assigning organisation HPI-Org-ID eg MC, NC . Do we need both a code MC and the OrgID G00004-H, - MC is easily recognisable as medical council.

# entry[].resource.note[].text
Perhaps an element 'registrationAuthority' element (reference to HPI Org) plus an 'administrationAuthority) - also a reference to HPI Org

# entry[].resource.description
The current HPI  Conditions on Practice - is not a codeable concept  , it is a 0..* each with 3 x  4,000 character text fields.

# entry[].resource.note[].text
If there's a chance that in the future it could be coded, then using the text fields of a CodeableConcept would work, and would mean that there wouldn't be a breaking change. If there is (almost) no change oif this, then we can change the datatype to string

# entry[].resource.description
Current HPI has granting institution city and granting institution country. These are required if you drop the issuer as a reference  organisation and have it as a text field

# entry[].resource.note[].text
These could be in the Organization,address element (which can be contained)

# entry[].resource.description
We did say we would limit telecom to PractitionerRole. However,  it may take some time before we have practitionerRole records for all the RA persons already on the HPI. We should reconsider adding telecom back in to Practitioner as an  interim step so that there is somewhere to retain contact details if no PractitionerRole exists for person..

# entry[].resource.description
Our preference is that ethnicity is made up of 
		Response Text                                      1..1
		ethnicity code                                        1..6
		Ethnicity code standard description      1..6
An updater would supply just the response text, it is the combination of what a respondent has ticked plus what they have written in the 'other' fields of the standard ethnicity question. The NHI/HPI would translate this response into the 6 ethnicity codes.

# entry[].resource.note[].text
This is what the ethnicity would look like in the Practitioner instance that is returned from the HPI. The way it is updated is another question. If the updater is supplying 'raw' data that the service then produces the  ethnicity codes from, it sounds like the updating should be an operation rather than a new Practitioner instance...