; CDA Pharmacy spec
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

CDA Pharmacy spec

VIEWS: 193 PAGES: 30

  • pg 1
									        CDA Pharmacy specification for
        Pharmacy Dispensing Repository
                                                                 Version 0.86


                                                 Thursday, 11 September 2008
                                                             Revision History


Name          Date                Reason for change                Version
David Hay     Friday, 27 June     Initial creation                 .1
              2008
David hay     Monday, 14 July     After sysmex meeting             .2
              2008
David hay                         Set the Id to a GUID             .3
David hay     Monday, 11 August   Notes about mixtures and         .4
              2008                dispensing Id
David Hay     Monday, 11 August   HPI not available                .5
              2008
David Hay     Tuesday, 12 August Fixed error with DOB              .6
              2008
David Hay     Wednesday, 13       Tidying and error fixing         .7
              August 2008
David Hay                         Added phone and address info     .8
                                  to the custodian element
Derryn Gill   26 Auguse           Review                           .81
David Hay     Wednesday, 27       Alterations after review         .82
              August 2008
David Hay     Friday, 05          Add updates/deletes              .83
              September 2008
David hay     Thursday, 11        After review by Derryn Gll       .86
              September 2008      (sysmex)




                                                                             1
Background .................................................................................................................... 4
   Documents ................................................................................................................. 4
Use Cases ....................................................................................................................... 4
   Dispensing Use Case.................................................................................................. 5
       Usual Flow ............................................................................................................. 5
   Prescription delete ...................................................................................................... 6
       Description ............................................................................................................. 6
       Usual Flow ............................................................................................................. 6
   Prescription modifications ......................................................................................... 6
       Description ............................................................................................................. 6
       Usual Flow ............................................................................................................. 6
Message structure........................................................................................................... 7
   Proprietary vs Standard .............................................................................................. 7
   HL7 version ............................................................................................................... 7
Architecture.................................................................................................................... 8
Implementer Notes ......................................................................................................... 8
   Resources ................................................................................................................... 8
   Privacy ....................................................................................................................... 9
CDA Overview ............................................................................................................ 10
   Document Versioning .............................................................................................. 10
CDA Header................................................................................................................. 10
   Header elements ....................................................................................................... 11
       <typeId> ............................................................................................................... 11
       <templateId> ........................................................................................................ 11
       <id> ...................................................................................................................... 11
       <code> ................................................................................................................. 12
       <title> ................................................................................................................... 12
       <effectiveTime>................................................................................................... 12
       <confidentialityCode> ......................................................................................... 12
       <recordTarget> .................................................................................................... 12
       <author> ............................................................................................................... 14
       <custodian> .......................................................................................................... 15



                                                                                                                                   2
CDA Body ................................................................................................................... 15
   <Section> element ................................................................................................... 17
   <text> element ......................................................................................................... 18
   <confidentialityCode > ............................................................................................ 18
   <entry> element ....................................................................................................... 18
       <substanceAdministration> ................................................................................. 19
       <effectiveTime>................................................................................................... 19
       <routeCode> ........................................................................................................ 20
       <doseQuantity> .................................................................................................... 20
       <consumable> ...................................................................................................... 20
       <entryRelationship>............................................................................................. 21
Eclair Display............................................................................................................... 21
Dispense Id................................................................................................................... 22
Updates and Deletions ................................................................................................. 22
   Message structure..................................................................................................... 23
   Scenarios .................................................................................................................. 24
   Message Processing ................................................................................................. 24
Mappings...................................................................................................................... 25
   Simple prescriptions................................................................................................. 25
       Simple drug, atomic dosage ................................................................................. 25
       Simple drug, non-atomic dosage.......................................................................... 25
   Mixtures ................................................................................................................... 26
       Mixture with pharmacode .................................................................................... 27
       Mixture without pharmacode ............................................................................... 27
OIDs ............................................................................................................................. 28
Issues ............................................................................................................................ 29




                                                                                                                                    3
Background
This document is an implementation guide and message specification for the
Pharmacy Dispensing Repository (PDR) project being managed by healthAlliance on
behalf of the Auckland region. This project is intended to create a repository of
medication dispensings that can then be made available to clinicians (Primary and
Secondary) that are involved with the patients care. It is accepted that this will not be
a complete list, but will still assist with improving clinical quality.
At the same time that this project was being established (although quite
independently), HISAC has been promoting a national ePharmacy standard, and this
project logically fits as part of that standard. It has been agreed with HISAC that this
project will be part of the national e-pharmacy implementation.


Documents
There are 3 documents in the PDR Architecture & design document set:


Document Name           Purpose
CDA Pharmacy            Defines the format of the dispensing message that is sent by
Specification (this     the pharmacy to the DHB. This message is an HL7 CDA
document)               document (level 3) with a coded body.
External Access         Describes how external systems (the pharmacy computer and
Specification           the pharmacist) access the system across the health network
Internal messaging      Defined the internal architecture within the DHB that accepts
Architecture            the dispensing message via a web service interface and sends it
                        to the Eclair repository for processing and storage.


(There are other documents that describe the user requirements, user interface design
and others)



Use Cases
The Use cases that are being fulfilled by this specification are the dispensing
messages use cases only.




                                                                                            4
Dispensing Use Case
 sd Pharmacy transmission

                                                                              web service


            Patient            Pharmacy                      Authentication                                  processing      failure message
                                                              mechanism                                     message folder         folder

                present prescription


                 supply medication


                                       create messages to send


                                              Authenticate



                                                                     Repeat
                                                         send message


                                                                                     Validate


                                                                                            [Valid]: save

                                                                                                       [invalid]: save


                                                             response




Usual Flow
     1. The patient attends the pharmacy to have a prescription fulfilled.
     2. The pharmacist completes the prescription and dispenses the medication. The
        activity is recorded in the system. (Alternative flows such as a partial dispense
        or a substitution are not covered in this implementation)
     3. At a given time the system assembles messages representing the dispensing
        activities and submits that to the repository. Each message contains the
        dispensings for a single patient. The system have a built in “delay” period
        where only dispensings that have been in the system longer that that delay will
        be sent. This is to allow errors to be correct before message submission.
     4. The use case ends.
From the perspective of the caller, the only errors that will currently be returned will
relate to structural errors in the message. If there are business related errors (such as
an invalid pharmacode) then this will be detected during later processing by Eclair,
but not returned electronically to the calling system.




                                                                                                                                       5
Prescription delete
Description
This use case describes the scenario where a dispensing message has been sent, but is
subsequently found to be incorrect. An example is where a pharmacy makes up a
“regular” set of medications for a rest home, but subsequently discovers that the
patient has been moved from the rest home. The script need to be deleted.
Another scenario is where the patient hands in the script, but fails to pick up all (or
part) of the medication

Usual Flow
   1. The pharmacist recognises that a dispensing is incorrect, and deletes it. The
      system recognises that a message has already been sent to the repository.
   2. The system constructs a message that contains the dispensing details (as they
      were originally send), but marks the dispensing as been deleted (see the
      section on updates and deletions on page 22.
   3. The message is sent to the repository.
   4. Upon receipt, the repository marks the dispensing as deleted.


Prescription modifications
Description
This use case describes modification of a dispensing that has already been sent and
corrects it in the pharmacy Practice Management System (PMS) prior to giving the
medication to the patient. It is expected that the delay between entering the
medication details into the PMS and the message generation should mininise the
number of times that this occurs.

Usual Flow
   1. The pharmacist recognises that a dispensing is incorrect, and modifies it in the
      PMS. The system recognises that a message has already been sent to the
      repository.
   2. The system constructs a message that contains the dispensing details (as they
      were originally sent), but marks the dispensing as been modified (see the
      section on updates and deletions on page 22.
   3. The message is sent to the repository.
   4. Upon receipt, the repository updates the dispensing data.




                                                                                          6
Message structure
These are simple use cases, but there are a number of issues that were addressed when
producing the interface design.

Proprietary vs Standard
The format of the message from pharmacy to repository could either be one that is
proprietary to the new Zealand environment, or follow some international standard.
The international standard (HL7) was chosen, as this allows international best practice
to be followed, and will produce an architecture that is extensible. Further, it means
that the work that needs to be done by vendors will be useful in other markets.

HL7 version
There are 2 possibilities in HL7 – version 2 or version 3.
Version 2 is a well accepted standard that has been used internationally for many
years. However, it is a standard that is focused purely n the exchange of data, rather
than the structure of the data itself. The newer version, version 3, has been re-
designed to „model‟ the data content first, before representing it in a message. There is
general agreement internationally that v3 will eventually replace v2 – it is a matter of
„when‟, not „if‟.
Another factor in the favour of v3 is that a number of other initiatives are built on a
version 3 rather than version 2 framework. One of these is the „IHE‟ initiative, an
international effort designed to facilitate interoperability between systems. A profile
that is of interest in New Zealand – XDS or Cross Enterprise document Exchange
does use HL7v2, but only as a transport mechanism rather than representing the
content.
For these reasons, the HL7 v3/CDA standard was chosen. CDA (Clinical Document
Architecture) is a standardized way of representing clinical information. It can be
transported either by a web service or a messaging infrastructure (often embedded in a
v2 message as the payload).
Other reasons why CDA was selected include:
          The document is human readable – either directly or via a stylesheet
          It is relatively simple to implement (much more so than v3 messaging),
           and yet is build on the foundation as v3 (The RIM – Reference
           Information Model), and thus is hugely extensible for future needs.




                                                                                          7
Architecture
The architecture is described in a separate document (the external access architecture),
and at a high level involves the transmission of the CDA documents from the
Pharmacy to the healthAlliance servers using a web service over the health network.
Strategically, it is intended to eventually use the XDR or XDS profile, which is a
reliable point to point protocol that is part of the IHE (www.ihe.net) suite of profiles.
However, this profile is still in the trial implementation stage, and the extra work
involved to implement it has not been allowed for in this project. So for the moment, a
proprietary protocol will be used with the intention of moving to XDS (or some other
nationally agreed protocol) once that has been defined.
The following high level use case describes how the transmission will occur in this
implementation.
   1. At a point in time (probably daily) the pharmacy system will select all
      dispensings that have not yet been transmitted to the repository, and group
      them by NHI
   2. A series of XML documents will be created – one for each patient dispensing
   3. The document will be sent by a series of web service calls to the
      healthAlliance system.
   4. The healthAlliance system will perform structural validation of the messages
      and return any errors.
   5. If there are no structural errors, it will then acknowledge receipt of the
      message, and pass the XML documents to the Eclair application for
      processing.




Implementer Notes
Resources
To assist the implementer, there are a number of documents/services that are
available.
          This document is the definitive implementation guide. It will be available
           on-line (at the NZHUG site) and will be updated as required over the
           course of the project.
          There will be a number of sample files released both with the
           implementation guide and as part of the NZHUG site that has been
           established. This will include an XSLT stylesheet that can render a CDA
           document as an HTML file.
          NZHUG has created an email account - cdahelp@hl7.org.nz - that
           implementers can use to get assistance. There is also a page on the
           NZHUG web site (www.hl7.org.nz) that will be used to post resources as
           they become available. (Check out “CDA Resources” under the “HL7
           Resources” menu item).



                                                                                        8
          There are a number of on-line validators that can be used to determine if a
           document is valid according to the CDA specification. These include:
                   o http://www.alschulerassociates.com/validator/
                   o http://hl7.org.ar/_nanocda/validate.htm
                   o And NZHUG will be posting a validator that is specific to this
                     implementation. This will include a test end-point for the
                     submission of batched data.
          The CDA specification itself can be downloaded from
           http://www.hl7.org/v3ballot/html/infrastructure/cda/cda.htm
          There is a „quick start‟ guide to CDA and CCD available at
           http://www.alschulerassociates.com/cda/?topic=quick-start-guides
          For xpath queries, there is a rather nice tool (sketchpath) that allows you to
           run xpath queries across XML documents at
           http://pgfearo.googlepages.com/
          To examine XML documents you can always use XMP Spy
           (http://www.altova.com ) or a much cheaper tool called XMLShell at
           http://www.softgauge.com/. There is also a free tool (XMLCopy) at
           http://xml-copy-editor.sourceforge.net/


Privacy
The privacy of data is critical in a healthcare setting. In this implementation, the
recipient system (testsafe) has the concept of „opt-off‟ – meaning that the particular
medication should not be displayed to the end user.
In CDA, this is defined by the <confidentialityCode> element – indicating the level of
confidentiality. For this implementation the following values will be accepted:
          N = Normal – any authorized clinician can read
          R = Restricted – only those with a current care relationship can access
          V = Very Restricted – as determined by the privacy officer.
Both „N‟ and „R‟ will apply to the current Eclair security levels, V will be equivalent
to „opt off‟ – ie the record will not be displayed (This is part of the business
requirement for the project – i.e. that there is a mechanism to avoid showing particular
entries if the patient wishes to hide them).
This element can be applied either at the document level (which means that it applies
to the whole document, or at the section level – meaning that it applies to the contents
of the section. The document level is required, the section level is optional.
In this implementation, privacy will be applied at the section level.
          The document level <confidentialityCode> will always have the value „N‟
          There can be up to 2 <section> elements, one containing „normal‟
           medications, the other containing „opt-off‟ medications, with an
           appropriate <confidentialityCode> element.



                                                                                         9
CDA Overview
A CDA document has two major components:
             The header is always an XML structure, and contains key information
              about the document (such as the document type, date it was generated,
              who it is about and so forth).
             The body can either be an XML structure, or a base-64 encoded „blob‟. If
              it is an XML structure, then it can either just contain text, or text and
              codes. In this implementation is will contain text and codes – often
              referred to as a „level 3‟ document.
The CDA specification is a „subset‟ of the full HL7 vs RIM (Reference Information
Model. (Technically it is a DMIM – Domain Information Model) that is specifically
intended for the representation and transfer of data in clinical documents. It could be
argued that there other HL7 v3 constructs that are better suited to this use case, but the
huge advantage of CDA is its simplicity and ease of implementation – which is why it
has been chosen.
From the perspective of the implementer, they only need to „fill in the blanks‟ based
on the information in this document to have a compliant CDA document.
Note that the CDA specification has a large number of options and can code a wide
range of clinical content. This implementation uses only a small subset of that
capability (and is restricted to that subset).

Document Versioning
The CDA specification supports document versioning (e.g. when there has been an
error or there is an update available). However, this is not appropriate for this
implementation and will not be supported.

CDA Header
The CDA Header contains information about the document – ie who is it about, who
created it, when it was created etc.
The following table gives a reference for the key data items that are stored in the
header and where they are stored. The header contents are then discussed in more
detail. Note that in most cases any one item actually has more components than
shown in this table – for example the NHI is in an element:
<id extension="PRP1660" root="2.16.840.1.113883.2.18.2"/>
Where the extension attribute is the actual NHI, and the root attribute identifies that it
comes from the NHI namespace. Refer to the sample documents when unclear.


Data Item         Location in document                                    Notes
NHI               recordTarget/ patientRole/ id /@extension


First name.       recordTarget/ patientRole/ patient / name/ given        There can be multiple
                                                                          first names



                                                                                        10
Last name       recordTarget/ patientRole/ patient / name/ family      There can be multiple
                                                                       last names
Date of Birth   recordTarget/ patientRole/ patient/ birthTime          Date is in
                                                                       YYYYMMDD
                                                                       format
Gender          recordTarget/ patientRole/ patient/
                administrativeGenderCode
Opt-off         confidentialityCode/ @code                             Set this code to „V‟
                                                                       (very restricted) to
                                                                       indicate that the
                                                                       entire document is
                                                                       opt off


Pharmacist      author/ assignedAuthor/ assignedPerson/ name           Contains the name
                                                                       and Id of the
                author/ assignedAuthor/ id
                                                                       pharmacist
Pharmacy        custodian/ assignedCustodian/                          The Id & name of
                representedCustodianOrganization/ id                   the Pharmacy
                custodian/ assignedCustodian/
                representedCustodianOrganization/ name


Dispensing      This is actually stored in the <supply> element for
date            each medication.



Header elements
The following section describes the elements of the CDA header in more detail. It is
suggested that the sample document „dispense.xml‟ should be available when it is
being read, as this will make the description more understandable.

<typeId>
The <typeId> is a fixed element that identified the document as a CDA document. It
is the same for all CDA documents, including the values of the root and extension.
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

<templateId>
The <templateId> is a fixed element that identifies the document as complying with
this specification. Ie it is a CDA document (and so will validate against the CDA
schema) but is further restricted to the elements defines in this specification.
<templateId root=" 2.16.840.1.113883.2.18.7.1 " />

<id>
The id of the document is a unique identifier for the document. This is assigned by the
creator of the document. For this implementation, this will be a GUID created at the


                                                                                       11
time that the document is created. (The actual value of the GUID will be different in
each message of course)
<id root=" 936DA01F-9ABD-4d9d-80C7-02AF85C822A8" />



<code>
The <code> element is used to indicate what type of CDA document this is. It uses
the LOINC coding system. For this implementation, the attributes are fixed as
follows:
<code code="34820-1" codeSystem="2.16.840.1.113883.6.1"
codeSystemName=”LOINC” displayName="Pharmacy Dispensing Note"/>

<title>
This is simply a human readable title for the document. For this implementation it is
suggested that it should be “dispensing Report”, but could be changed if required.
<title>Dispensing Report</title>

<effectiveTime>
This is the time that the report was generated. The format is YYYYMMDDHHNNSS
– ie Year – Month – Day – Hours – Minutes – Seconds. This is the standard format
for all <effectiveTime> elements.
<effectiveTime value="20080607155217"/>

<confidentialityCode>
This element is used to indicate the level of confidentiality of the contents of the
document. For this implementation the following values will be accepted:
            N = Normal – any authorized clinician can read
            R = Restricted – only those with a current care relationship can access
            V = Very Restricted – as determined by the privacy officer.
Both „N‟ and „R‟ will apply to the current Eclair security levels, V will be equivalent
to „opt off‟ – ie the record will not be displayed (This is part of the business
requirement for the project – i.e. that there is a mechanism to avoid showing particular
entries if the patient wishes to hide them).
<confidentialityCode code="N"/>

<recordTarget>
Identifies the patient that this document refers to. The table at the top of this section
describes the specific elements where each part of the patient information is located.
Note that there are many other elements that could be used about the patient (such as
address and contact details) if required in future revisions.
Notes about the data stored in these elements:
       NHI               The attribute @extension holds the actual NHI of the
                           patient.
                         The attribute @root is fixed at


                                                                                            12
                            2.16.840.1.113883.2.18.2      (It is an OID that
                            represents the NHI)
                          The attribute @ assigningAuthorityName is fixed at
                            “NHI”. This is included to assist with processing
                            be the Eclair repository


      First name     A patient can have any number of first names, each in a
                     <given> element. If there is more than one <given>
                     element, then the receiving system will concatenate
                     them into a single string separated by spaces.
      Last name      A patient can have any number of first names, each in a
                     <family> element. If there is more than one < family >
                     element, then the receiving system will concatenate
                     them into a single string separated by spaces.
      Prefix         A patient can have a <prefix> element such as Dr. or
                     Ms.
      Suffix         A patient can have a <suffix> element such as „the
                     third‟.
      Gender         The Gender is in a truly awful element called the
                     <administrativeGenderCode>. The values allowed in
                     this implementation are „M‟, „F‟, or „U‟. The
                     codeSystem is fixed at 2.16.840.1.113883.5.1 (this is an
                     OID that defines the possible value set for gender)
      Date of        The DOB is in the <birthTime> element. It has the
      Birth          format YYYYMMDD (although can record the time of
                     birth if known or useful).


<recordTarget>
       <patientRole>
             <id extension="PRP1660" root="2.16.840.1.113883.2.18.2"
assigningAuthorityName="NHI"/>
                <addr>
                         <streetAddressLine>23 Thule St</streetAddressLine>
                         <city>Auckland</city>
                         <country>New Zealand</country>
                </addr>


                <patient>
                         <name>
                                <given>david</given>
                                <family>hay</family>
                         </name>



                                                                                13
                        <administrativeGenderCode code="M"
                        codeSystem="2.16.840.1.113883.5.1"/>
                        <birthTime value="19551216"/>
               </patient>
       </patientRole>
</recordTarget>


Note that the optional middle name (if known) is a duplication of the <given> element
– eg:
       <name>
               <given>david</given>
               <given>ian</given>
               <family>hay</family>
       </name>


The <address> child element is optional.

<author>
The author represents the person (or thing) that generated the document. In this
implementation the author of the document will be the pharmacist that dispensed the
medication, and the pharmacy where the dispensing occurred.
The details of the Pharmacist are in 2 places in this element:
           Their id (the pharmacy guild registration code) is in the <id> element
           Their name is in the <assignedPerson><name> element (the options are
            the same as for the patient).
<author>
       <time value="20080607155217"/>
       <assignedAuthor>
               <id extension="SMIJOH" root="2.16.840.1.113883.2.18.9" />
               <assignedPerson>
                        <name>
                               <given>Peter</given>
                               <family>Smith</family>
                        </name>
               </assignedPerson>
       </assignedAuthor>
</author>




                                                                                     14
<custodian>
In CDA, the custodian of the document is the entity that is responsible for maintaining
the document. In this implementation it will be the Pharmacy that generated the
document.
<custodian>
       <assignedCustodian>
               <representedCustodianOrganization>
                    <id extension="GHP" root="2.16.840.1.113883.2.18.10"
assigningAuthorityName=" HealthPac claimant number "/>
                       <name>Good Health Pharmacy</name>
                              <telecom use="WP" value="09 665 4476"/>
                              <addr>
                                       <streetAddressLine>45 Pine
St</streetAddressLine>
                                       <city>Auckland</city>
                                       <country>New Zealand</country>
                              </addr>
               </representedCustodianOrganization>
       </assignedCustodian>
</custodian>


Note that the entry for <streetAddressLine> can be duplicated if there is more than
one line.



CDA Body
As mentioned above, this implementation uses „level 3‟ of CDA, which means that
the CDA body is not only a structured XML document, but the data within it is also
coded, which means that it can be „understood‟ by both sender and recipient. This is
achieved by a couple of mechanisms:
          The CDA schema is an international standard, defined and maintained by
           HL7. Thus any application claiming compliance with CDA can readily
           demonstrate this.
          There is a common vocabulary that is understood by all parties. Indeed
           there are a number of vocabularies – some of which are a part of the CDA
           standard, but another – the Pharmac formulary – is a New Zealand
           standard. Thus, when a drug is represented in a CDA document, reference
           is made to the underlying formulary (via the Pharmacode)
The CDA body comprises any number of sections, where each section contains the
data pertaining to a particular aspect of the information within the document. In this
implementation there is only a single type of section containing the medications
prescribed, however this would be easily extensible to support other aspects such as
allergies, problem list or key problems.


                                                                                         15
This guide allows for 2 „instances‟ of the medication section – one for medications
that can be displayed to a secondary user, and one that is „opt-off‟ – ie cannot be
displayed. The value of collecting „opt-off‟ medications is that it does alert the
clinician to the existence of medications, and gives them the opportunity to enquire
the details directly from the patient who can then choose to answer or not.
A key „philosophy‟ of CDA is that the document must be human readable – both
directly or, more commonly, by a style sheet. This is achieved by placing the readable
version of the data in the <text> element, backed up by coded data in the <entry>
elements. The CDA specification allows for data to be in the <text> element but not
in an <entry> element, but this is not allowed in this implementation, due to the
requirement that data is to be imported into the Eclair repository. (Note that the
inverse is not permitted in CDA – ie data in an <entry> element not also represented
in the <text> element).
A high level view of the hierarchy of the body is:


structuredBody
   component (can be up to two, depending on „opt-off‟)
      section
         title
         text
         confidentialityCode             (optional)
         entry       (repeats any number of times)
            substanceAdministration
                effectiveTime
                effectiveTime
                routeCode
                doseQuantity
                consumable
                  manufacturedProduct
                     manufacturedMaterial
                        code
                           originalText
                        name
                entryRelationship
                  supply
                     quantity




                                                                                       16
<Section> element
As described above, the record of the prescription and the dispensing are stored in a
<section> element under the <structuredBody><component> root.
There can be up to 2 sections – one containing medications to be displayed, and one
containing medications that are not to be displayed („opt-off‟).
The <section> element (which, in CDA can be used for a number of purposes) has a
number of child elements.
          A single <templateId> element that identifies that the section is compliant
           with this specification. The value of the @root attribute is fixed at
           2.16.840.1.113883.2.18.7.1.1, and no @extension attribute is required
          A single <code> element that defines that this section holds medication
           information. The @code and @codeSystem attributes are fixed:
               <code code="10160-0" codeSystem="2.16.840.1.113883.6.1"/>

          A single <title> element that provides user legible description of the
           section. This is fixed with a value of “Medications”
          A single <text> element that contains a human legible version of the coded
           data in the remainder of the section. This element is described further on
           page 18.
          Any number of <entry> elements, each of which describes a single
           prescribed medication. Refer to page 18 for details.
There are a number of key concepts with CDA that are useful to review at this point.
          The <text> element must contain a human readable version of the data that
           is contained in the <entry> elements. In other words, every drug (or other
           item) that is coded in a <entry> element must also appear in the <text>
           element. This is to ensure that a person could view a CDA document, and
           understand its meaning. Note that is is quite legal to have data in a <Text>
           element that is not in an <entry> element, although that is not used in this
           implementation.
          With regard to coded medications, there is an implicit understanding that
           the codes are referencing an agreed formulary. In the case of this
           implementation guide, this is the pharmacode. This reference is found in
           the entry/ substanceAdministration/ consumable/
           manufacturedMaterial/ code /@code attribute. If this code is not a valid
           pharmacode, then the document should be rejected. Mixtures are split into
           2 areas; Multi component packaged medicines and all these has associated
           Pharmacodes. Mixtures made on-site don‟t have Pharmacodes but each of
           the individual ingredients do. This means codes need to be accepted using
           a local defined code (not sure what this will be at this stage) The value of
           this is that the recipient system can reference the formulary to acquire data
           that may not be in the document. An example of this is the strength (or
           product size) of a medication – which is not held separately in CDA.
           However, it can be retrieved form the formulary based on the pharmacode.




                                                                                        17
<text> element
As described above, the <text> element must contain all the data represented in the
coded <entry> elements (it can contain more than that). This is to ensure that the
document as a whole is human readable - either directly or as a result of an XSLT
stylesheet transformation.
There are a number of options in this element, but in this implementation it will be
assumed that the medications will be represented as a simple list. Note that the
intention of this element is that it is human readable, and so the format of the items
can be different to that specified in the coded data.
<text>
          <list>
                    <item>Aspirin (Cartia) 10mg tablet, 2 tablets twice a day PO. 100 tablets
                    dispensed on Jan 1, 2008.</item>
                    <item>Clopidogrel (Plavix) 75mg tablet, 1 tablet a day PO. 100 tablets
                    dispensed on Dec 1, 2006.</item>
          </list>
</text>

<confidentialityCode >
This has the same meaning as defined in the header of the document – that the entries
defined in this section can be made private. Refer to the discussion on page 9 for
details.
 <confidentialityCode code="N" />                 a „normal‟ section
 <confidentialityCode code="V" />                 „opt off‟ medications, don‟t display

<entry> element
The entry element is where each medication is actually coded. The CDA specification
allows for a large number of options in this element, such as patient instructions,
directions to the pharmacy, indications, interactions and many more. For the purpose
of this implementation, only a small subset of these options will be used.
It is likely that future versions of the guide will expand the capabilities, but these will
always be backward compatible due to the conformance to CDA (and ultimately back
to the RIM).
The <entry> element has a number of direct children, some of which have children of
their own.
<entry>
          <substanceAdministration classCode="SBADM" moodCode="EVN">
                    <effectiveTime/>
                    <effectiveTime xsi:type="PIVL_TS">
                           <!-- How often to take the medication-->
                           <period value="12" unit="h"/>
                    </effectiveTime>
                    <routeCode code="PO" codeSystem="2.16.840.1.113883.5.112"
                    displayName="oral"/>



                                                                                             18
               <doseQuantity value="2" unit="tablet"/>
               <!-- how many to take in each administration-->
               <consumable>
                       <manufacturedProduct>
                              <manufacturedMaterial>
                                   <code code="101326"
codeSystem="2.16.840.1.113883.6.88" codeSystemName="Pharmac"
displayName="Aspirin 10mg">
                                              <!-- from the pharmacode-->
                                              <originalText>Aspirin</originalText>
                                              <!-- generic name-->
                                      </code>
                                      <name>Cartia</name>
                                      <!-- brand name -->
                              </manufacturedMaterial>
                       </manufacturedProduct>
               </consumable>
               <entryRelationship typeCode="REFR">
                       <supply classCode="SPLY" moodCode="EVN">
                              <effectiveTime value="20080101"/>
                              <quantity value="100" unit="tablets"/>
                       </supply>
               </entryRelationship>
       </substanceAdministration>
</entry>




<substanceAdministration>
The <substanceAdministration> element is what indicates that this <entry> is
referring to a medication. It has 2 attributes, both of which are fixed for this
implementation
          classCode is fixed at SBADM
          moodCode is fixed and EVN. (This indicates that the entry refers to an
           event – i.e. the dispensing has actually occurred.)

<effectiveTime>
This element has a couple of purposes in CDA.
          It can indicate the period over which the medication should be given
          It indicates how often the medication should be given




                                                                                     19
If an <entry> has two of these elements, then the first will be the period over which
the medication is active, and the second the dosage instructions. In this
implementation, both will be present, but only the second one will have significance.
(This is to preserve backwards compatibility).

<routeCode>
The <routeCode> element is used to indicate how the medication is to be taken – eg
orally, as a puff, topically etc. The codeSystem is set at 2.16.840.1.113883.5.112
which refers to the routeOfAdministration value set in HL7. The complete list can be
found at the URL
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/RouteOfAdministration.ht
m
But common options are:
                  @code                       Meaning
                  PO                          Orally
                  IPINHL                      Inhalation (puff)
                  TopicalApplication          Topical application


The @displayName attribute can also be used.

<doseQuantity>
This element indicates how many of the medication should be taken at any one time.
The actual use of this depends on how the medication is expressed in the
manufacturedMaterial\code\@code element.
          If this code refers to a tablet or other single „entity‟ then the @value
           attribute should be the number, and the optional @unit attribute the unit.
           Eg
               <doseQuantity value= “3” unit = “tablets”/>

          If this code refers to something that is not inherently a unit of some sort
           (such as a cream or a syrup) then this will refer to the amount. Eg
               <doseQuantity value= “5” unit = “ml”/>

<consumable>
The Consumable element refers to the actual medication that is being taken. It is
called consumable, as it is actually used up as it is used – unlike equipment would be.
For example this is where you could say that the actual drug being taken is aspirin,
10mg or Paracetamol 125mg /5ml. Again this can be a complex and sophisticated
element, but the usage in this implementation will be quite straightforward.
The <consumable> element has a number of children (actually grand-children):
          code
          name
The <code> element (actually consumable/ manufacturedProduct/
manufacturedMaterial/ code) is where the reference to the actual drug is made. As


                                                                                         20
mentioned earlier, it is a reference to a known formulary (the pharmacode) which
allows a recipient system to look up other characteristics of that drug in the formulary
if required. There are 3 key attributes (plus a fourth optional).
          code – the actual pharmacy code for this medication
          codeSystem – the OID that represents the Pharmac code set
          codeSystemName (optional) – fixed at „NZ Pharmac‟
          displayName – the name of the drug, according to the pharmacy code. This
           should include the dose and formulation as well as the medication name –
           eg Digoxin .125 mg tab. (This is strictly optional, but highly
           recommended)

<code code="269026" codeSystem="2.16.840.1.113883.6.88" codeSystemName="NZ
Pharmac" displayName="Aspirin 10mg">


The <code> element can also contain a child element - <originalText>. If present, this
refers to the generic name of the medication
<originalText>Aspirin</originalText>
The <name> element (actually consumable/ manufacturedProduct/
manufacturedMaterial/ name) can be used to hold the brand name.
<name>Cartia</name>

<entryRelationship>
The <entryRelationship> element is used to link two things (technically „acts‟) in
CDA together. In this situation we are using it to link the medication that was
prescribed (in the <substanceAdministration> element) with the amount that was
actually dispensed. The value of doing it this way is that it would allow the
representation of a situation where what was actually dispensed is different to that
which was ordered - for example, where there was a generic substitution.
In this implementation, we are using it solely to record how much of the medication
was actually dispensed, using a <supply> element. The <quantity> child records the
amount dispensed, and the <effectiveTime> element records the time that the
dispensing took place.
<entryRelationship typeCode="REFR">
       <supply classCode="SPLY" moodCode="EVN">
               <effectiveTime value="20080101"/>
               <quantity value="100" unit="tablets"/>
       </supply>
</entryRelationship>

Eclair Display
The following section describes where the individual elements of the Eclair display
would be derived from, as currently defined in the requirements.




                                                                                       21
Generic Name       This could come from the <originalText> element, or from the
                   Pharmac formulary
Brand Name         This could be from the <manufacturedMaterial><name> element, or
                   from the Pharmac formulary

Strength           If this must be a separate column, then it will need to come from the
                   formulary. However, it will also be present in the
                   code/@displayName attribute
Form               If this must be a separate column, then it will need to come from the
                   formulary.
Sig                The instructions field is actually a concatenation of a number of
                   other fields in the <entry> element:
                   <doseQuantity> + <effectiveTime>


Date               This will be the supply/ effectiveTime/ @value attribute in
                   YYYYMMDDHHNN format
Quantity           Supply / quantity
Pharmacy           The pharmacy name is actually in the CDA header, and applies to all
Name               the medications in the document. author\ assignedAuthor\
                   representedOrganization\ name


Dispense Id
When a medication is dispensed, the dispensing system generates an Id that is unique
to that system (but not outside the system) that identifies the particular dispense. This
Id is represented by the <id> child element of the <substanceAdministration>
element. (For a mixture, this will be the parent element).
However, there is a difficulty in using this element, as the dispense Id is not unique
outside of the pharmacy that dispensed it. For our implementation, we will adopt the
following convention:
         The “root” attribute will be the OID for the claimant number
         The “extension” attribute will be a compound value containing the actual
          claimant number for the pharmacy and the dispense Id separated by a dot.
          Thus, if the claimant number for the pharmacy is 12345 and the dispense Id is
          888, then the value of the <id> element will be:
  <id root="2.16.840.1.113883.2.18.10" extension="12345.888" />



Updates and Deletions
There are a number of circumstances where data that has already been sent to the
repository needs to be modified. (Refer to the Use Cases on page 6). This section
describes how these modifications can be sent to the repository for processing.




                                                                                        22
Message structure
Ideally we want to use the same message structure (CDA) for all messages. This
should be possible with the use of one of the optional elements in the
<substanceAdministration> element – the „<statusCode> element – which indicates
the status of the element. Usually we can leave this blank, but to indicate an error, we
can use a value of „cancelled‟ to indicate that the dispensing has been cancelled.
Thus:


<substanceAdministration classCode="SBADM" moodCode="EVN>
        …
        <id … />
        <statusCode code="cancelled"/>
        …
</substanceAdministration> …




…would indicate that the dispensing in the element was not given



<substanceAdministration classCode="SBADM" moodCode="EVN>
        …
        <id … />
        <statusCode code="amended"/>
        …
</substanceAdministration> …




…would indicate that the dispensing in the element should replace existing data




        The specific dispense item to alter can be determined from the <id>
        child element of the <substanceAdministration> element, as this
        identifies both pharmacy and dispense Id. Refer page 22 for details




                                                                                     23
Scenarios

Scenario        Pharmacy action                              Eclair processing
A medication    Re-send the message with the same data       Locate the data item in Eclair
dispense did    (including Id> in the                        with the
not occur and   <substanceAdministration> element,           substanceAdministration\id\@
was deleted     and a new child element of                   extension value, and mark it as
after a                                                      deleted in Eclair.
                <statusCode code=”cancelled”/>
dispense
message was
sent
A medication    Re-send the message with the same data       Locate the data item in Eclair
was altered     (including Id> in the                        with the
after the       <substanceAdministration> element            substanceAdministration\id\@
dispense        and with the correct data in the             extension value, and overwrite
message was     substanceAdministration element.             (or version) the existing data
sent                                                         with the new data.
                Add a child element
                                                             Note that Eclair should always
                <statusCode code=”amended”/>
                                                             check whether there has been an
                                                             entry with an existing extension
                                                             value to preserve data integrity,
                                                             so the amended value is strictly
                                                             unnecessary.




Message Processing
The message specification allows for multiple dispensings to be sent in a single message
(although they must be for the same patient as indicated in the header). In theory, if there
are any modifications to the data, then the entire CDA document should be resent (with a
number of attributes indicating version changes).
For this implementation, we will not require this.
For example, if a CDA message with 5 dispensings is sent, and one of them subsequently
needs to be deleted, then this can be achieved by sending a single message containing
only the dispense to be deleted.




                                                                                          24
Mappings
The section shows how drug information is mapped into the CDA entry element in a
number of scenarios.
For samples, refer to „CDA Resources‟ link in the website (http://www.hl7.org.nz ) which
has sample documents.
When implementing the extract, the validate is a useful resource – both for pasting in a
CDA document and clicking the „validate‟ option, and also for loading the default CDA,
modifying it directly in the text box, and clicking „validate‟ to see if the resulting
document is still valid.

Simple prescriptions
Simple drug, atomic dosage
This is for a simple medication, which has a pharmacode, and the dosage information can
be extracted in atomic form – ie not as a simple text string. This format is preferred, as it
enables a recipient system to calculate the actual dose of the drug (if this is required)
rather than having this in a non-parsable string.
Item               xpath
Pharmacode         substanceAdministration/ consumable/ manufacturedProduct/
                   manufacturedMaterial/ code
Generic            substanceAdministration/ consumable/ manufacturedProduct/
                   manufacturedMaterial/ code/ originalText
Trade              substanceAdministration/ consumable/ manufacturedProduct/
                   manufacturedMaterial/ name
Dose per           substanceAdministration/ doseQuantity
administration     (This gives the number of „units‟ of medication as defined in the
                   pharmacode)
Frequency of       substanceAdministration/ effectiveTime[2]/ period
administration     (the period element indicates how often the medication is taken)
Amount             substanceAdministration/ entryRelationship/ supply/ quantity
Dispensed
When               substanceAdministration/ entryRelationship/ supply/ effectiveTime
dispensed


Simple drug, non-atomic dosage
This is for a simple medication, which has a pharmacode, but the dosage information is
not atomic – but rather present as a text string „take 3 tablets after meals until finished‟.
This option is less preferred as the dosage data is viewable by a human, but not
computable.


                                                                                                25
In this scenario, the elements <effectiveTime>, <routeCode> and <doseQuantity> are
absent – replaced by a single <text> element.


Item              xpath
Pharmacode        substanceAdministration/ consumable/ manufacturedProduct/
                  manufacturedMaterial/ code
Generic           substanceAdministration/ consumable/ manufacturedProduct/
                  manufacturedMaterial/ code/ originalText
Trade             substanceAdministration/ consumable/ manufacturedProduct/
                  manufacturedMaterial/ name
Administration    substanceAdministration/ text
instructions
Amount            substanceAdministration/ entryRelationship/ supply/ quantity
Dispensed
When              substanceAdministration/ entryRelationship/ supply/ effectiveTime
dispensed



Mixtures
Mixtures are where the medication that is dispensed is made up of more than one
component – each of which is defined separately.
The mixture is represented in CDA by a normal <substanceAdministration> element that
represents the mixture (name, dose etc) which has a number of „child‟
<substanceAdministration> elements, each of which describes one of the components of
the mixture.
The contents of the parent <substanceAdministration> element will vary according to
whether the mixture as a whole has a pharmacode – described further in the sections
below. See previous note regarding pharmacodes, mixtures
Each child <substanceAdministration> element is „nested‟ within an <entryRelationship>
element which has a typeCode attribute of „COMP‟ – indicating a component.
The following shows how this works at a high level.
<substanceAdministration>
        … other stuff about the mixture – amount to take, frequency etc…
        <entryRelationship typeCode=”COMP”>
               <substanceAdministration>
                      … details of first component …
               </substanceAdministration>
        </entryRelationship



                                                                                      26
               <entryRelationship typeCode=”COMP”>
               <substanceAdministration>
                      … details of second component …
               </substanceAdministration>
       </entryRelationship
       <entryRelationship typeCode=”REFR”>
               <supply>
                      … details of supply …
               </supply>
       </entryRelationship
</substanceAdministration>



Mixture with pharmacode
This is a „standard‟ mixture with a pharmacode that represents the mixture. Note that in
this case it is not necessary to specify the components, but it is desirable for
completeness.
The parent <substanceAdministration> element contains the dosage instructions. This can
either be „atomic‟ or text (as described in the section above on simple drugs).
The <manufacturedMaterial> element of the parent <substanceAdministration> contains
both <code> and <name> elements – representing the pharmacode and name of the
mixture.
Each child <substanceAdministration> element has the same structure as for a simple
drug.
      If the child element has a pharmacode, then it will be represented by a <code>
       element
      If the child element does not have a pharmacode, then there will only be a
       <name> element

Mixture without pharmacode
This is where the chemist has „created‟ a mixture based on a variable combination of
other substances. Some of the components may have a pharmacode, but the mixture
overall does not.
The layout is the same as the mixture with pharmacode, with the exception that the
<manufacturedMaterial> element of the parent <substanceAdministration> contains only
the <name> elements – representing name of the mixture.


Item              xpath
Mixture name      substanceAdministration/ consumable/ manufacturedProduct/


                                                                                           27
                 manufacturedMaterial/ name
Mixture dosage substanceAdministration/ doseQuantity + substanceAdministration/
               effectiveTime[2]/ period
Amount           substanceAdministration/ entryRelationship/ supply/ quantity
Dispensed
When             substanceAdministration/ entryRelationship/ supply/ effectiveTime
dispensed
First
component
Pharmacode       substanceAdministration/ entryRelationship/
                 substanceAdministration[1]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ code
Generic          substanceAdministration/ entryRelationship/
                 substanceAdministration[1]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ code/ originalText
Trade            substanceAdministration/ entryRelationship/
                 substanceAdministration[1]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ name
Second
component
Pharmacode       substanceAdministration/ entryRelationship/
                 substanceAdministration[2]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ code
Generic          substanceAdministration/ entryRelationship/
                 substanceAdministration[2]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ code/ originalText
Trade            substanceAdministration/ entryRelationship/
                 substanceAdministration[2]/ consumable/ manufacturedProduct/
                 manufacturedMaterial/ name




OIDs
OID‟s (or Object Id‟s) are a construct that allow an identifier to be globally unique. In
CDA, it is primarily used as a scoping system – ie to provide a „namespace‟ within which
there is an identifier that is unique within that namespace. For example, the New Zealand
NHI will have an OID that represents that namespace. Within the NHI namespace are the
actual NHI numbers that identify individuals. Thus an NHI is represented as:
<id extension="PRP1660" root="2.16.840.1.113883.2.11.1.4"
assigningAuthorityName="NHI" />



                                                                                       28
where the „extension‟ attribute is the patients actual NHI, and the „root‟ attribute is the
OID that represents the NHI namespace. The assigningAuthorityName is a textual
equivalent of the root – generally it is not necessary to have both, but in this
implementation it is included to assist with processing by Eclair.
When constructing documents, implementers can use the OID‟s that are in the sample
documents, particularly for OID‟s that are part of the CDA specification (eg the OID in
the typeId element).
The reason the OID is so long is that it is globally unique. From the perspective of the
implementer, you simply need to use the OID supplied in this document. In this
document you will see OID‟s used in <id> and <code> elements.
The following OID‟s are defined for this implementation.


Entity          Description                                    OID
Pharmac         Represents the pharmacy coding system –        2.16.840.1.113883.2.18.4
                the pharmacode
NHI             Represents the NHI coding system               2.16.840.1.113883.2.18.2
Pharmacy        Uses the claimant number – assigned by         2.16.840.1.113883.2.18.10
                healthpac
Pharmacist      Represents the Pharmacist - the pharmacy       2.16.840.1.113883.2.18.9
                guild Id
The             Represents the version of the CDA (as          2.16.840.1.113883.2.18.75.1
dispensing      defined by this implementation) used for
document        dispensing information in New Zealand.
Dispensing      Defines the <section> element in this          2.16.840.1.113883.2.18.7.1.1
section         implementation




Issues
This section lists a number of issues that remain outstanding, and will need to be clarified
before the specification can be completed. However, none of these issues should
materially effect the specification.


Pharmacy Id             Not HPI
Code the prescriber     Should the medication prescriber also be present in the document.
Routecodes              What is the list of route codes that needs to be supported
Periodicity             What periodicity details are needed – eg times per hour, bd tds
                        etc. Should all of these be „decomposed‟ into times per hour for


                                                                                              29
simplicity, plus/minus a separate patent instructions section?




                                                                 30

								
To top
;