Difference between revisions of "Implementasjonsguide HL7"

Latest revision as of 12:26, 22 June 2011

Introduction

All services in this document are based on the Normative Edition 2008 of HL7 version 3. The intent of this document is to describe the key aspects of the services and the HL7 v3 documents related to them. For additional information about HL7 and the HL7 version 3 standards, see http://en.wikipedia.org/wiki/HL7 and http://hl7book.net/index.php?title=HL7_version_3

NOTE: This is an extract from the real implementation guide, only for presentation here on wiki.HL7.no. For complete version with structures of messages, please check out [1].

Definitions and relationships

Definitions used in this document:

OID Object Identifiers NNPR Norwegian National Population Register (Folkeregister)

Assumptions

• A1: For privacy reasons the author (a person) of a query that is related to the demographics data of a patient/person should be sent. Medical data is subject to additional privacy/auditing regulations.
  • Audit logging should be compliant to: http://www.shdir.no/samspill/informasjonssikkerhet/norm_for_informasjonssikkerhet_i_helsesektoren_232354.
  • Based on the requirements above, a decision has been made to include (in those messages not automatically generated by a software application) the “user identifier” of the person sending a message in all messages.

• A2: In all communication the patient will be identified using the F-Number (if available); the D-number (if the F-number isn’t available). Within Helse Vest other identifiers may be sent in addition to the F or D-number.
  • In the first phase H-numbers as defined by KITH should be used. http://www.kith.no/templates/kith_WebPage____609.aspx

• A3: The standard used will be Normative Edition 2008 of the HL7 version 3 standard. The IHE HL7 v3 profiles aren’t used – the Norwegian requirements go beyond the restricted model used in that profile.

• A4: The F-Number as well as the D-Number is used to both identify a person as well as a person-in-the-context-of-healthcare (a patient).

• A5: There will be one patient master (PAS) and there is one person master (Folkeregister).

• • There will be a maximum of one person.id (either the F-number or the D-number –in that order of preference-), and a maximum of one Patient.ids (either the F-number, the D-number or the H-number –in that order of preference-). All other known Ids for the Patient (older, previously used, temporary Ids, non-preferential IDs) should be sent in the OtherIds.id attribute.
• A6: There is a tightly controlled process when it comes to the merging of patient identifiers. The un-merging of previously merged patient identifiers rarely happens.
  • There will be a notification interaction from the Patient Registry to other applications. This to inform these applications that it should merge all data associated with a set of patient identifiers.
  • There won’t be a notification from the Patient Registry in case identifiers are un-merged: this remains a manual process.
  • An interaction from an application to the Patient Registry to request that identifiers be merged (as well as un-merged) won’t be supported. Merges are exclusively made in the Patient Registry itself.

Architecture of Identity and Demographics data management

The architectural model related to the management of person/patient identifiers and demographics data is based on one core principle: there will be one patient master (Patient registry, PAS) and there is one person master (Person Registry, Folkeregister).

• A new patient can only be created within the Patient Registry. This could either be a manual process using the Patient Registry application, or another software application could use a service to request that the Patient Registry create a new patient.
• All updates related to patient demographics (including the merging of patient identifiers) are made available by the Patient Registry to other software applications in the form of notifications.
• To get hold of the latest demographic information (and the best quality in terms of identifiers) software applications can query the Patient/Person Registry using an identifier of the Patient/Person.
• In order to determine whether a patient/person is already present in the registry software applications have the option to search for potential matches using partial demographics person/patient information.

500px

Implementation of Notifications

The concept of notification messages is based on other systems subscribing to changes of some specified information elements in the patient administrative system. The patient administrative system is referred to as EPJ (Electronic Patient Journal). Activation of specified events will trigger the EPJ to publish notifications to a middleware solution (for example Microsoft BizTalk Server) which will distribute the notification messages to the subscribing systems or services. The following figure illustrates the concept for the Patient Registry Duplicates Resolved message.

File:Notifications.jpg

Services

This chapter contains the description of a number of services. The semantic interchange model used by the services is based on the international HL7 version 3 standards.

PatientRegistry

See pages below for details of the various methods:

• PatientRegistry.GetDemographics
• PatientRegistry.RecordRevised
• PatientRegistry.FindCandidates
• PatientRegistry.Addpatient

PersonRegistry

See pages below for details of the various methods:

• PersonRegistry.GetDemographics
• PersonRegistry.FindCandidates

CareRecordmanager

Method: CareRecordManager.GetCareRecordProfile

This storyboard illustrates the use of this method. It involves querying a Care Record Manager application for a list of encounters that are ongoing or have taken place in the past, including the discharge diagnoses associated with those encounters.

Find Last 20 Encounters Adam Everyman is at home and suffers a sudden onset of chest pain. The pain continues during the next half an hour. Eve Everyman, his wife, calls the emergency phone number. Nurse Nightingale at the emergency unit identifies the patient (using the patient name, birth date and gender: Patient Registry Find Multiple Candidates). Using the patient identifier (F-number 24035412356) she initiates a Get Care Record Profile Query to get hold of the last 20 (inpatient/outpatient) encounters of Adam Everyman, including discharge diagnoses related to those encounters. The returned information provides her with contextual information for the clinical history. She notices that Adam has had frequent encounters with the Cardiology department, associated with diagnoses codes ‘minor stroke’ and ‘high blood pressure’. She orders an ambulance and sends a message related to a planned encounter to the Good Health Hospital emergency room application. Nurse Theresa receives the message from the emergency room application about Adam Everyman and she initiates a Get Care Record Profile Query to get hold of the last 20 encounters of Adam everyman, including discharge diagnoses related to those encounters. She can see that Adam Everyman has been at the Cardiology department on May 4, 2008, and based on this information she requests additional data from that departmental system in preparation of the arrival of the patient.

The querying system sends a query with a person identifier to a Care Record Manager application. The query will be either based on the F-number, the D-number, or an Emergency patient identifier.

The query interaction has an immediate response. The response interaction will contain the details of all known historic and ongoing encounters. Both the querying application (if it explicitly requests so) as well as the responding system may introduce an upper limit in the number of encounters returned.

Each interaction is defined in the form of two wrappers (which contain meta-data related to the information exchange) and a so-called payload model. The payload model of the query interaction is shown here: http://www.hl7.org/v3ballot2008MAY/html/domains/uvpc/uvpc_CareRecordQuery.htm#QUPC_RM040300UV-rmi

The payload model of the response interaction is shown here: http://www.hl7.org/v3ballot2008MAY/html/domains/uvpc/uvpc_CareRecord.htm#REPC_RM004000UV-rmi

EncounterManager

Method:EncounterManager.FindEncounters

This storyboard demonstrates querying an Encounter Manager (an application which contains information about encounters) for both active and completed encounters. This use case is also known as “who is here”, or “who is sitting in the waiting room”.

File:Encounters.jpg

Textual storyboard #1: Patient Eva Everywoman enters the waiting room of the Ear, Eye and Mouth Unit (EAM) and reports to the desk of the Simone Support, the secretary of the EAM Unit. Simone registers Eva as being “present”, and requests Eva to take a seat. Dr. Mike Molar, a dental surgeon who works for the EAM unit, opens a module in his software application and requests to see a list of all those persons that are available in the waiting room of the EAM Unit and waiting for the start of an outpatient (ambulatory) encounter (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN101351NO). Dr. Molar sees that Eva is present and has been waiting the longest time. He goes to the waiting room and asks Eva to join him in his office for a consultation.

Textual storyboard #2: Dr. Eric Eye, an eye specialist who works for the EAM unit, opens a module in his software application and requests to see a list of all those persons that have been admitted for an inpatient stay -and that are still present in the hospital (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN101351NO). Dr. Eye sees that one of the patients he’s been consulted for is still in the hospital and decides to call his colleague to see if further consultation will be necessary.

Textual storyboard #3: Simon Support, a secretary at the clinical biochemistry laboratory, requests the sample list for the 8 o’ clock round at the children’s clinic. The sample list software application queries the encounter manager for the location, down to bed-level) of each patient on the list (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). The complete sample list is printed out and given to the staff responsible for the sample collection round. Textual storyboard #4: Clerk Kent, a secretary at the radiology department has a list of inpatients scheduled for examination during the day. As the appointment for the patient Adam Everyman is getting close, Kent opens a module in his software application and request to see at which ward Everyman is admitted. (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). Kent then makes a phone call to the ward and asks them to have the patient delivered to the examination room in 30 minutes.

Textual storyboard #5: Bill Costly, the secretary responsible for preparing the invoices at the radiation therapy department, has a list of all patients treated the last day. For each patient on the list, Costly opens a module in his software application and request to see if the patient was an inpatient or outpatient at the time of the treatment. (Find Encounters Query, PRPA_IN900301NO, and Find Encounters Query Response, PRPA_IN900351NO). If the patient was an outpatient, Costly prepares an invoice.

The query interaction has an immediate response. The response interaction will contain the details of all known encounters that match the search criteria as listed in the query interaction. The number of encounters in the response interaction is maximized to 250 encounters. If 250 encounters are returned in a response interaction one should sent the query again with more specific query parameters.

Method: EncounterManager.FindScheduledEncounters

Note: Description of interactions and message content is known to be incomplete (notably in the area of the identification of the equipment). A new version of this implementation guide will contain a finalized description.

This storyboard demonstrates querying a Schedule Manager (an application which contains information about scheduled encounters) for planned encounters.

File:FindScheduledEncounters.jpg

Textual Storyboard #1: Dr. Rudolf Röntgen, a Radiologist, has been informed that his patient, Eve Everywoman, has arrived in the waiting room of the Radiology department. Dr. Röntgen opens a module in his software application and requests to see what imaging equipment has been scheduled for Eve. (Find Appointments Query, PRSC_IN010701NO, and Find Appointments Query Response, PRSC_IN010751NO). He sees that her examination is scheduled to take place using imaging equipment known as ‘CT number 1’.

Textual Storyboard #2: Dr. Rudolf Röntgen, a Radiologist, opens a module in his software application and requests to see a list of all patients that are scheduled to have an examination (today) involving the imaging equipment known as ‘CT number 1’. (Find Appointments Query, PRSC_IN010701NO, and Find Appointments Query Response, PRSC_IN010751NO). Dr. Röntgen sees that the next appointment is in 10 minutes, for patient Eve Everywoman.

The query interaction has an immediate response. The response interaction as sent by the EncounterManager will contain all known scheduled encounters that match the search criteria as listed in the query interaction.

DocumentManager

The DocumentManager supports a series of services related to the management of documents in a document archive.

A document is a persistent (unchangeable) object. Whenever a document is transmitted (e.g. a document in a PDF format, a TIFF image, or a CDA document) one has to send document management metadata alongside the actual document object.

Method: DocumentManager.ProcessNewDocument

This storyboard demonstrates the sending of a new document to a document management archive.

File:ProcessNewDocument.jpg

Textual Storyboard #1: Dr. Simon Surgeon has performed an operation earlier today and decides to write a ‘Surgery Note’ document. Once he has finalized the document he decides to share it with others in his hospital by uploading it to the central document archive (Original Document with Content, RCMR_IN000002NO.)

The notification interaction has an immediate response in the form of an Accept Acknowledgement. Note that an Accept Acknowledgement serves both as an assurance that the interaction was received, and as a statement that the interaction was –at a glance- syntactically correct.

Each interaction is defined in the form of two wrappers (which contain meta-data related to the information exchange) and a so-called payload model. The payload model of the Document Notification interaction is shown here: http://www.hl7.org/v3ballot2009jan/html/domains/uvmr/uvmr_DocumentManagement.htm#RCMR_RM000050UV02-rmi

The Accept Acknowledgement response interaction has no payload. Its definition can be found here: http://www.hl7.org/v3ballot2008MAY/html/domains/uvci/uvci_GenericMessageTransmission.htm#MCCI_IN000002UV01-int

See the electronic archive for example XML-instances.

Method: DocumentManager.ProcessDocumentReplacement

This storyboard demonstrates the notification to a document management archive by the author of a document that the document has been/will be replaced by a newer version.

File:DocumentReplacement.jpg

Textual storyboard #1: Dr. Simon Surgeon has made a ‘Surgery Note’ available to the centralized document archive. He finds out that that document needs to be corrected, so he notifies the centralized document archive (Document Replacement, RCMR_IN000015NO) that the document has been, or will be, replaced by a corrected version of the document.

The notification interaction has an immediate response in the form of an Accept Acknowledgement. Note that an Accept Acknowledgement serves both as an assurance that the interaction was received, and as a statement that the interaction was –at a glance- syntactically correct.

Each interaction is defined in the form of two wrappers (which contain meta-data related to the information exchange) and a so-called payload model. The payload model of the Document Notification interaction is shown here: http://www.hl7.org/v3ballot2009jan/html/domains/uvmr/uvmr_DocumentManagement.htm#RCMR_RM000050UV02-rmi

The Accept Acknowledgement response interaction has no payload. Its definition can be found here: http://www.hl7.org/v3ballot2008MAY/html/domains/uvci/uvci_GenericMessageTransmission.htm#MCCI_IN000002UV01-int

See the electronic archive for example XML-instances.

Model Elements

Object Identifiers (OID)

OIDs are an ISO mechanism for the unique identification of objects. Within the context of HL7 interactions OIDs are quite often used to uniquely identify an identification scheme (a particular methodology for the identification of a class of objects, e.g. HPR-number) or a coding system (a terminology; a table of codes; e.g. ICD-10, Sivilstand). For an introduction to OIDs, see http://www.ringholm.de/docs/00900_en.htm

Commonly used OIDs (i.e. used for a purpose that is wider in scope than the regional healthcare organization; used in communications between healthcare regions) can be found in OIDs registries such as www.oid-info.com, www.hl7.org, HL7 OID registry in the UK (http://www.hl7.org.uk/version3group/oids.asp) and in Norway www.volven.no.

NOTE! www.volven.no does only present the last part of the OID their branch (2.16.578.1.12.4.1) must prefix all OID before they are referenced.

Helse Vest is used as an example representing a regional healthcare organization throughout this document.

The Helse Vest OID is: 2.16.578.1.34. Helse Vest will use subbranches of that OID to identify objects or coding systems. Updated information: http://www.oid-info.com/get/2.16.578.1.34

Coding Systems

The following are OIDs for coding systems:

Identification Schemes

The following are OIDs for identification schemes (Helse Vest is used here as an example of a Healthcare org). :

Data Types

Patient and Person identifiers

Most of the patients treated in Norwegian health care are registered in the Norwegian Person registry (Folkeregister) and have a unique eleven digit number. This person identifier is also used to identify the patient. Two types of identifier exist:

• The F-Number: this identifier is also used to identify the patient. The F-Number is assigned to persons living in Norway on a permanent basis.
• The D-Number: Persons that are not living in Norway on a permanent basis can in some circumstance be registered in NNPR with a unique eleven digit number (a D-number).

These identifiers are meaningful to the user of a software application and hence are shown to the user.

A Patient may have one or more other patient identifier assigned within a regional healthcare organization. These identifiers shall not be communicated outside of the organization. Identifiers assigned within a regional healthcare org. may include:

• Temporary identifier: An application within the organization may assign an emergency/temporary identifier (H-Number) to a patient. Most of these identifiers are linked to either an F-number, a D-number or a PAS-identifier at a later point in time.

The Patient Registry has its own internal identifier for a patient’s “set of demographics data – including the above patient identifiers”:

• Internal PAS identifier: the PAS application within the regional healthcare organization will assign a unique internal identifier. This identifier is used exclusively for electronic communications and should never be shown to a user.

The following XML-snippet is an example of how these identifiers are conveyed as part of the HL7 version 3 model:

   <!- Response contains one of F/D/H number, and the internal DIPS patient ID -->
   (see RULE#1)
   <id root="2.16.578.1.34.1000.1" extension="24109642356" assigningAuthorityName="F-Number"/>
   
   ... patient demographics ..
   <patientPerson>
       <!- ONE Person identifier from the Folkeregister: here: F number -->
      (see RULE #2)
       <id root="2.16.578.1.34.1000.1" extension="24109642356"/>

       <asOtherIDs>
      (see RULE#3)
           <!- Used to convey all old/ non-preferential IDs. Here: the old D-Number for this person/patient -->
           <id root="2.16.578.1.34.1000.2" extension="64109642356" assigningAuthorityName="D-Number"/>
       </asOtherIDs>
    </patientPerson>

When it comes to identifiers the following rules apply:

1. The Patient class shall have at least 1, and at most 2 identifiers: Either the F-number or the D-number (in that order of preference; if both a F-number and a D-number are known, only the F-number shall be sent here), and the temporary identifier.
2. The Person class shall have at most 1 identifier: Either the F-number or the D-number (in that order of preference; if both a F-number and a D-number are known, only the F-number shall be sent here).
3. The OtherIDs class shall contain all other known identifiers: the D-number if the F-number is also known; old temporary identifiers; non-preferential F-number if the F-number of the person changed/merged, etc.

Patient name

The structure of the name follows the Folkeregister and divides the name into two (or three) parts:

<name>

  <given>Ola</given>
  <given>Petter</given>
  <family>Nordmann</family>

</name>

Names from Folkeregistrert should be marked with use=OR=Official registry.

<name use=”OR”>

  <given>Ola</given>
  <given>Petter</given>
  <family>Nordmann</family>

</name>

Previous/birth/maiden name is supported using the validTime attribute. ValidTime (with attributes low and high) specifies the validity range of the name.

 <name>
    <given>Jan</given>
    <given>Helge</given>
    <family>Nielsen</family>
    <validTime>
       <high value="20000101"/>
    </validTime>
  </name>

Note that the name attribute is repeating, i.e. multiple (types of) names could be sent. It is up to the receiver (based on the value of the use attribute, and validTime) to decide what name it wants to use or import in its database.

Address

The address data type will be used as follows:

• streetAddressLine for street name and house number. streetAddressLine may occur multiple times.
• postalCode for ZIP/postal code
• city for city (poststed)
• country defaults to Norway, and should be used for addresses outside of Norway.

When it comes to the address of the patient, the address from the Folkeregister shall be sent as part of the Person (entity) class, using the HP use code.

<!- The postal address from Folkeregister -->

 <patientPerson>
    <addr use="HP ">
       <streetAddressLine>Hallskaret 72</streetAddressLine>
       <postalCode>5117</postalCode>
       <city>ULSET</city>
    </addr>
 </patientPerson>

In addition to the Folkeregister address the Patient may have other (temporary) addresses. These shall be sent as part of the Patient (Role) class. Only H (Home), WP (Workplace), PST (Postal address) and TMP (temporary) shall be used a use code, HP is reserved for the Folkeregister address.

<!- The temporary postal address is manually entered -->

 <patient>
    <addr use="H PST">
       <streetAddressLine>Thormøhlens gate 12</streetAddressLine>
       <postalCode>5006</postalCode>
       <city>BERGEN</city>
   </addr>
 <\patient>

Example of a foreign address, followed by a temporary Norwegian Address: <!- The postal address is manually entered -->

  <addr use="H PST">
      <streetAddressLine>Storgatan 123</streetAddressLine>
      <postalCode>464 05</postalCode>
      <city>MELLERUD</city>
      <contry>Sverige</contry>
  </addr>
   <addr use="TMP PST">
      <streetAddressLine>Thormøhlens gate 12</streetAddressLine>
      <postalCode>5006</postalCode>
      <city>BERGEN</city>
  </addr>

C/0 address can be used when the contact party is visiting someone, living temporary or get mail sent to work, and her or his name is not on the mailbox. Example of a C/O (care of) address: <!- The postal address is manually entered -->

 <addr use="TMP PST">
  <careOf>c/o Jane Doe</careOf>
  <streetAddressLine>Somewhere Road 1<streetAddressLine>
  <postalCode>1234</postalCode>
  <city>A Place</city>

</addr>

Telephone and mail

All telecommunication devices used by a person or patient are modelled as URLs. The voice telephone URLs begin with “tel:” fax URLs begin with "fax:" and mail address with “mailto”.

    <telecom use="H" value="tel:55354257" /> 
    <telecom use="H" value="fax:56542558" /> 
    <telecom use="WP MC" value="tel:97555786" /> 
    <telecom use="WP" value="mailto:tor.nordmann@helse-vest-ikt.no" /> 
    <telecom use="H" value="mailto:tor.nordmann@broadpark.no" /> 

The following codes will be used in the “use” attribute:

• H – Home
• WP – Work
• MC can be used (in addition to H or WP) to denote that this is a mobile phone.

Country codes shall be used if the telephone/fax number is located outside of Norway. The default country code (if not explicitly listed) is +47.

Administrative Entity associated with a Patient or Person

Next to the postal address the patient is part of (an inhabitant of) an administrative entity within Norway. The identification of the administrative entity is of importance for a multitude of organizational/administrative purposes, e.g. it has an impact on financial arrangements between the administrative entities, as well as on the choice of preferential healthcare provider organizations where care is delivered.

Depending on where the patient lives this can be either specified using a code to identify a Kommune (and the Fylke as well), or a code to identify the Bydel (and the Kommune and Fylke as well), or (for those living outside of Norway): a code for the Fylke as well as a code for the country of residence.

There are two special values to denote that persons are located outside of Norway:

1. NO-9900 Within EU/EEA
2. NO-9000 Outside EU/EEA

The Administrative Entity is identified the following way:

1. Three observations, one for Fylke, one for Kommune and one for Bydel (ADMFYL, ADMKOM, ADMBYD respectively)
2. and one single observation with the ADMREG observation code (see section 4.3.7 for a description of the code).

In addition, an additional observation will be sent if the patient has moved from Norway to another country:

• An observation with the ADMSTT observation code (see section 4.3.7 for a description of the code). This observation may only be sent in combination with the values NO-9900 and NO-9000.

Note: The person registry methods do not have support for this kind of information. If the person has moved from Norway, no administrativeObservationEvent element will be returned.

Note: in version 1.0 of this specification ADMREG was the only observation used. As of version 1.1 the administrative region will be sent containing all representations (up to four observations).

Example 1: If the administrative entity is known as precise as a Bydel (in large cities):

<Patient>
... other elements ...
 <subjectOf>
   <administrativeOservationEvent>
       <code code="ADMFYL" codeSystem="2.16.578.1.34.5.1"/>
       <value xsi:type="CE" code="NO-12" displayName=" Hordaland" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
   </administrativeOservationEvent>
</subjectOf>
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMKOM" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-1201" displayName="Bergen, Hordaland" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMBYD" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-120108" displayName="Åsane (Bergen, Hordaland)" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>
<subjectOf>
   <administrativeOservationEvent>
       <code code="ADMREG" codeSystem="2.16.578.1.34.5.1"/>
       <value xsi:type="CE" code="NO-120108" displayName="Åsane (Bergen, Hordaland)" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
   </administrativeOservationEvent>

Example 2: If the administrative entity is known as precise as a Kommune:

<Patient>
 ... other elements ...
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMFYL" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-12" displayName="Hordaland" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMKOM" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-1201" displayName="Bergen (Hordaland)" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMREG" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-1201" displayName="Bergen (Hordaland)" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>

Example 3: If the person has moved from Norway to Sweden:

<Patient>
 ... other elements ...
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMREG" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="NO-9900" displayName="Within EU/EEA" codeSystem="1.0.3166.2.2" codeSystemName="ISO 3166-2:2007"/>
    </administrativeOservationEvent>
</subjectOf>
<subjectOf>
    <administrativeOservationEvent>
        <code code="ADMSTT" codeSystem="2.16.578.1.34.5.1"/>
        <value xsi:type="CE" code="SE" displayName="Sweden" codeSystem="1.0.3166.1.2" codeSystemName="ISO 3166-1:2007"/>
    </administrativeOservationEvent>
</subjectOf>

Coding Systems

Maritalstatus (sivilstand)

The Folkeregisteret uses the following coding system (with OID 2.16.578.1.34.1000.6) for Maritalstatus (Sivilstand):

0 = Uoppgitt 1 = Ugift 2 = Gift 3 = Enke/-mann 4 = Skilt 5 = Separert 6 = Registrert partner - Partnership between person of same sex 7 = Separert partner 8 = Skilt partner 9 = Gjenlevende partner

Example: <maritalStatusCode code="2" codeSystem="2.16.578.1.35.1000.6"/>

Administrative Gender

The administrative gender indicates the gender of a person. Values are: M (Male), F (Female) and UN (Undefined – ambiguous). The codes are taken from the HL7 AdministrativeGender coding system with OID 2.16.840.1.113883.5.1.

Example:

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>

Healthcare organization types

As coding system for organization types in healthcare (e.g. hospital, GP practice, etc.), the identification scheme for Norwegian organizations will be used. (Enhetsregisteret – Brønnøysund) The OID of the coding system is 2.16.578.1.34.1000.5. The OID has been assigned by Helse Vest, but might be replaced by Brønnøysundregisterets own OID at a later time.

Healtcare provider types

A coding system for healthcare provider types (person roles within healthcare organizations, e.g. physician internal medicine, head nurse, radiologist) has yet to be decided upon.

The HPR register is a candidate, it uses the following concepts (without codes): Ambulansearbeider, Apotektekniker, Audiograf, Bioingeniør, Ergoterapeut, Fotterapeut, Fysioterapeut, Helsesekretær, Hjelpepleier, Jordmor, Kiropraktor, Klinisk ernæringsfysiolog, Lege, Omsorgsarbeider, Optiker, Ortopediingeniør, Ortoptist, Perfusjonist, Provisorfarmasøyt, Psykolog, Radiograf, Reseptarfarmasøyt, Sykepleier, Tannhelsesekretær, Tannlege, Tannpleier, Tanntekniker, Vernepleier.

Job code

A coding system for Job types has yet to be decided upon. Candidate: Jobcallcode – www.ssb.no.

EncounterTypes

The table below shows the ActEncounterCode (2.16.840.1.113883.5.4) coding system, which identifies the type of encounters.

Administrative Observation types

A coding system for Administrative Observations related to Persons and Patients. The coding system has OID 2.16.578.1.34.5.1.

The coding system contains the following coded concepts:

Wrapper Elements

This section documents some of the aspects of the wrappers as used in HL7 version 3 interaction.

All HL7 version 3 interactions contain a Transmission Wrapper, an optional Trigger Event Control Act Wrapper (mostly referred to as the ControlAct Wrapper, present in 99% of all interactions) and a so-called Payload (in 90% of interactions there is exactly 1 payload, some interactions –notably responses to queries- may contain zero or multiple payloads).

Transmission Wrapper

The Transmission Wrapper has the aim to identify the sending and receiving applications, the time that the interaction was sent, as well as some other meta data related to the interaction. The description below is limited to those elements used in this project.

Example:

<PRPA_IN201307NO ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"	>
  <id extension="3948375" root="2.16.578.1.34.1.145.1"/>
  <!- Time message was sent -->
  <creationTime value="20080719140010"/>
  <versionCode code="NE2006plus"/>
  <!- Fixed values for GetPatientDemographics query -->
  <interactionId extension="PRPA_IN201307NO" root="2.16.840.1.113883.1.6"/>
  <processingCode code="P"/>
  <processingModeCode code="T"/>
  <acceptAckCode code="NE"/>
  <receiver>
    <device>
    <!- Receiving software application. Helse Vest assigned application identifier -->
        <id extension="922" root="2.16.578.1.34.1"/>
    </device>
  </receiver>
  <sender>
    <device>
    <!- Sending software application. Helse Vest assigned application identifier -->
    <id extension="145" root="2.16.578.1.34.1"/>
    </device>
  </sender>
  <controlActProcess>
  ....
  </controlActProcess>
</PRPA_IN201307NO>

Generic Payload Models

This section documents some of the payload models used in multiple HL7 version 3 interactions.

Generic Person palyload model

Generic Patient payload model

Error Handling

HL7 version 3 contains an elaborate mechanism for the identification of errors, warnings and informative messages.

The most important attribute when it comes to the identification of errors in a response interaction is the Acknowledgement.typeCode (see section 4.4.1). The value of this attribute indicates whether or not the original interaction could be successfully processed or not.

The following codes are used for the response interaction MCCI_IN000002UV02:

• CA - Success
• CE - Error

The following code are used for all other interactions:

• AA – Success
• AE – Error

In the current implementation phase the error handling is limited to errors related to the contents of query parameters only. Examples of such errors include missing parameters in a query, wrong parameter format (e.g. have a letter were there should be a number), or the use of an illegal F-/D-number format. In case of this category of parameter related errors:

• QueryAck.queryResponseCode shall be set to QE (see section 4.4.2), and

' AcknowledgementDetail.typeCode shall be set to AE (see section 4.4.1)

.The reasonOf element can be used in the response interactions to give a reason why a request is rejected. The OID of the coding system is 2.16.578.1.34.5.3. So far, the following error codes have been defined:

• KNOWNPAT - The patient is already known in the patient registry.
• VALIDATION - The query parameters are wrong or insufficient.
• AUTHENTICATION - The user cannot be authenticated.
• AUTHORIZATION - The user is not authorized.
• OTHER – Other errors. The attribute displayName may contain a useful error message.

Examples:

<reasonOf typeCode="RSON">
 <detectedIssueEvent moodCode="EVN" classCode="ALRT">
 			<code code="KNOWNPAT" codeSystem="2.16.578.1.34.5.3" displayName="Patient already known. This service requires a new patient." /> 
 		</detectedIssueEvent>
 </reasonOf>

<reasonOf typeCode="RSON">
 <detectedIssueEvent moodCode="EVN" classCode="ALRT">
 			<code code="VALIDATION" codeSystem="2.16.578.1.34.5.3" displayName="insufficient parameters in query" /> 
 		</detectedIssueEvent>
</reasonOf>

Mapping to other models

This section contains a mapping of the data provided by the Folkeregisteret and HL7 version 3 models.

The model below is the payload model used (with minor variations) in most interactions related to patient demographics.

500px

Folkeregisteret

The Norwegian Folkeregisteret (see http://www.skatteetaten.no/Templates/Artikkel.aspx?id=6640&epslanguage=NO for additional information) is a person registry.

WSDL and Schemas

WSDL documents are XML documents that describe services as a set of message-enabled or procedure-oriented abstract endpoints. These operations and/or messages and their associated data types are described conceptually, and then bound concretely to a network protocol, message format, and programming language as needed.

A WSDL document defines the following elements for describing services:

• Types: data type definitions
• Message: an abstract definition of the data being transferred
• Operation: an abstract description of a service procedure
• Port Type: an abstract set of operations supported by one or more endpoints
• Binding: a concrete protocol and data format for a given port type
• Port: a single endpoint defined as a binding and a network address
• Service: a collection of related endpoints or ports

This document is published jointly with a set of normative WSDL and Schemas. Together they are an expression of the contract on the 'wire level'. The WSDL provided in NE2008 v2 are strongly typed. That term refers to a service contract that contains a complete definition of its input and output messages in XML Schema, a schema that is either included in the WSDL definition or referred to by that WSDL definition.

The actual WSDL is specific as to the HL7v3 payload message contained in the <soap:Body> definition, with references to the actual schemas involved shown in listing below.

<types>
  <xsd:schema targetNamespace="urn:hl7-org:v3"...>
       <xsd:include schemaLocation="../schemas/QUPC_IN043100NO.xsd" /> 
 	<xsd:include schemaLocation="../schemas/QUPC_IN043200NO.xsd" /> 
	<xsd:element name="QUPC_IN043100NO-Response">
		<xsd:complexType>
			<xsd:choice>
 	            		<xsd:element ref="hl7:QUPC_IN043200NO" /> 
 			</xsd:choice>
 		</xsd:complexType>
 		</xsd:element>
 	</xsd:schema>
 </types>
	<message name="QUPC_IN043100NO">
 		<part name="body" element="hl7:QUPC_IN043100NO" />
</message>
	<message name="QUPC_IN043100NO-Response">
 		<part name="body" element="hl7:QUPC_IN043100NO-Response" /> 
 </message>
	<portType name="CareRecordQueryFulfiller_PortType">
		<operation name="QUPC_IN043100NO_Operation">
 			<input message="hl7:QUPC_IN043100NO" /> 
 			<output message="hl7:QUPC_IN043100NO-Response" /> 
 		</operation>
 </portType>

The published style of WSDL (“strongly typed”) describes the actual XML instances going in and out as well as the HL7v3 Schema's used. The WSDL can therefore easily be used to validate a service or guide in the design of a service. This generally increases the level of automation, code generation, tool support, and use of standardized middleware. It also produces more stable code and relieves the developer from having to create infrastructure level code. And even a generically implemented service can provide a strongly typed interface definition.

This 'contractual' flavour of WSDL and Schema is the only flavour that will be published, they are normative and the web services they describe should be implemented. Whether they are used 'as is' for code generation is an independent, often environment-dependent question, and vendors are free to use their own derived WSDL and (modified) schemas as long as the contractual WSDL is warranted.