Current Build

Переводит компания Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

3.3 FHIR Documents

FHIR Infrastructure Work GroupMaturity Level: 3Ballot Status: Trial Use

FHIR-ресурсы могут быть использованы для построения документов, которые представляют композицию: набор согласованной информации, которая является утверждением информации о здравоохранении, включая клинические обследования и службы. Документ - это иммутабельный набор ресурсов с фиксированным представлением, который создан и/или заверен людьми, организациями или устройствами. FHIR resources can be used to build documents that represent a composition: a set of coherent information that is a statement of healthcare information, including clinical observations and services. A document is an immutable set of resources with a fixed presentation that is authored and/or attested by humans, organizations and devices.

Документами, построенными таким способом, можно обмениваться между системами и сохранять в хранилище документов и системах управления, включая такие системы, как IHE XDS. Documents built in this fashion may be exchanged between systems and persisted in document storage and management systems, including systems such as IHE XDS.

Приложения, заявляющие о соответствии этому фреймворку, заявляют о соответствии "FHIR-документам" (см. Conformance). Applications claiming conformance to this framework claim to be conformant to "FHIR documents" (see Conformance).

FHIR-документы могут быть 'клиническими' (направленными на медицинскую информацию о пациенте), а также могут служить не клиническим целям (например FHIR Implementation guides, практические руководства, наглядные материалы для пациентов и т. п.). HL7 будет разрабатывать профили в будущем, давая дополнительное руководство по подходящему представлению клинических документов как в общем, так и в частных случаях клинических документов (например Consolidated CDA). FHIR documents may be 'clinical' (focused on patient healthcare information) but may also serve non-clinical purposes (e.g. FHIR Implementation guides, practice guidelines, patient handouts, etc.) HL7 will develop profiles in the future giving additional guidance on appropriate representation of clinical documents in general as well as specific types of clinical documents (e.g. Consolidated CDA).

Обратите внимание, что FHIR устанавливает и формат этого документа, и ресурс DocumentReference. FHIR-документы - для документов, которые созданы и собраны в FHIR, а ресурс ссылки на документы - для общих ссылок на pre-existing документы. Note that FHIR defines both this document format and a document reference resource. FHIR documents are for documents that are authored and assembled in FHIR, while the document reference resource is for general references to pre-existing documents.

Все документы имеют одинаковую структуру: a комплект ресурсов (Bundle) типа "document" с ресурсом Composition в качестве первого ресурса в комплекте, за которым следует серия других ресурсов, на которые имеются ссылки из ресурса Composition, который содержит подтверждающие данные для этого документа. Комплект собирает всё содержимое документа в единый XML или JSON-документ, который может быть подписан и администрирован по мере надобности. Ресурсы включают в себя и человекочитаемые, и обрабатываемые компьютером блоки. Кроме того, комплект может включать в себя каскадные таблицы стилей , заявления о происхождении (Provenance) и цифровую подпись. All documents have the same structure: a Bundle of resources of type "document" that has a Composition resource as the first resource in the bundle, followed by a series of other resources, referenced from the Composition resource, that provide supporting evidence for the document. The bundle gathers all the content of the document into a single XML or JSON document which may be signed and managed as required. The resources include both human readable and computer processable portions. In addition, the bundle may include CSS stylesheets , Provenance statements and a signature.

Ресурс Composition является основой клинического документа. Он: The composition resource is the foundation of the clinical document. It:

  • содержит именование и назначение и устанавливает контекст документа; provides identity and its purpose, and sets the context of the document
  • несет ключевую информацию, такую как объект и автор, и кто утвердил документ; carries key information such as the subject and author, and who attests to the document
  • делит документ на серию разделов, каждый со своим текстовым описанием divides the document up into a series of sections, each with their own narrative

Любой ресурс, на который есть прямая ссылка из Composition, ДОЛЖЕН быть включен в комплект во время сборки документа. В частности, это означает ссылки на следующие ресурсы: Any resource referenced directly in the Composition SHALL be included in the bundle when the document is assembled. Specifically, this means the following resource references:

Другие ресурсы, на которые ссылаются эти ресурсы, могут также быть включены в комплект, если такое решение примет система построения документа. Включение этих дополнительных ресурсов сделает документ больше, однако убережет приложения от необходимости получения связанных ресурсов, если они понадобятся им во время обработки документа. Таким образом решение о том, должны связанные ресурсы быть включены или нет, зависит от среды реализации. Other resources that these referenced resources refer to may also be included in the bundle if the document construction system chooses to do so. Including these additional resources will make the document bigger but will save applications from needing to retrieve the linked resources if they need them while processing the document. Thus, whether these linked resources should be included or not depends on the implementation environment.

Бандл типа документ ДОЛЖЕН включать только: The document bundle SHALL include only:

  1. Ресурс Composition и любые ресурсы, на которые есть прямая или косвенная (например рекурсивная) ссылка из него. The Composition resource, and any resources directly or indirectly (e.g. recursively) referenced from it
  2. Ресурс Binary, содержащий таблицу стилей (как описано выше). A Binary resource containing a stylesheet (as described below)
  3. Provenance-ресурсы, в элементе target которых указан ресурс Composition или другой ресурс, включенный в документ. Provenance Resources that have a target of Composition or another resource included in the document

У документа имеется два ключевых идентификатора: There are two key identifiers in the document:

  • Идентификатор документа (обязательный). Хранится в элементе Bundle.identifier, является глобально уникальным для этого экземпляра документа и никогда не используется повторно, в том числе и для других документов, извлекаемых из этой же композиции The document identifier (mandatory). This is found in Bundle.identifier and is globally unique for this instance of the document, and is never re-used, including for other documents derived from the same composition
  • Структурный идентификатор (необязательный). Он находится в Composition.identifierи является одинаковым для всех документов, содержащихся в композиции. The Composition identifier (optional). This is found in Composition.identifier, and is the same for all documents that are derived from this composition

В документе указывается несколько дат: The document has several dates in it:

  • Дата документа (обязательно). Она находится в Bundle.meta.lastUpdated и указывает, когда комплект документа был собран из лежащих в его основе ресурсов.
  • Дата композиции (обязательно). Находится в Composition.date, это дата, когда автор написал документ логически.
  • Даты утверждения (необязательно). Находится в Composition.attester.time , это дата, когда документ был засвидетельствован очевидцами. Обычно это будет то же самое время, что и дата композиции, либо позднее.
  • Дата последнего изменения композиции (необязательно). Находится в Composition.meta.lastUpdated и является датой последнего изменения композиции. Она должна быть >= дате композиции.

Комплекты документов могут быть подписаны электронными цифровыми подписями в соответствии с правилами, выложенными на странице цифровые подписи. Подпись ДОЛЖНА быть поставлена очевидцем из списка в документе и подпись ДОЛЖНА содержать элемент KeyInfo , содержащий элемент KeyName, значением которого является URI, совпадающий с fullUri соответствующего attester-ресурса. Document Bundles may be signed using digital signatures following the rules laid out in the digital signatures page. The signature SHOULD be provided by a listed attester of the document and the signature SHOULD contain a KeyInfo element that contains a KeyName element whose value is a URI that matches the fullUri for the matching attester resource.

Однажды собранный в комплект, документ становится иммутабельным - его содержимое больше не может быть изменено, а id документа не может быть повторно использован. Обратите внимание, что документ может быть представлен в XML либо JSON-формате, конвертироваться между ними или менять кодировку символов, и при этом оставаться тем же самым документом. Однако содержимое по прямым ссылкам из документа и представление документа не могут быть существенно изменены (таким образом, чтобы поменять клинический смысл содержимого). Все дополнительные документы, вытекающие из одной композиции, ДОЛЖНЫ иметь различные идентификаторы документа. Once assembled into a bundle, the document is immutable - its content can never be changed, and the document id can never be reused. Note that the document may be represented in either XML or JSON and interconverted between these or have its character encoding changed, all the while remaining the same document. However, the directly referenced content within the document and the presentation of the document cannot change substantially (such that it changes the clinical meaning of the content). Any additional documents derived from the same composition SHALL have a different document id.

При представлении документа человеку, приложения должны предъявлять объединенные описательные части в следующем порядке: When the document is presented for human consumption, applications SHOULD present the collated narrative portions in order:

  1. Описательная часть ресурса-субъекта
  2. Описательная часть ресурса Composition
  3. Описательная часть section.text

Такое представление документа называется "заверенным содержимым" документа. В бандл могут быть включены дополнительные ресурсы (например ресурсы, на которые ссыается ресурс List, составляющие section.content, ДОЛЖНЫ присутствовать в бандле, при этом другие, дополнительные ресурсы, на которые они ссылаются, тоже могут быть включены туда, но они (и любая описательная часть) не будут являться заверенным содержимым). В частности, Composition.attester заверяет представленную форму документа. The presentation of the document is called the 'attested content' of the document. Additional resources can be included in the bundle (e.g. resources referenced from the List that represent the section.content SHOULD be in the bundle, and other additional resources they reference can be included), but these (and any narrative) are not attested content. Specifically, the Composition.attester attests to the presented form of the document.

Описательная часть ресурса Composition должна суммировать важные части заголовка документа, которые требуются для установления клинического контекста документа (отличного от субъекта, который отображается сам по себе (in its own right). Фактически чтобы построить скомбинированную описательную часть, просто склейте все описательные <div>-фрагменты вместе. The Composition resource narrative should summarize the important parts of the document header that are required to establish clinical context for the document (other than the subject, which is displayed in its own right). To actually build the combined narrative, simply append all the narrative <div> fragments together.

Если документ представлен в другом порядке, отличном от описанного выше, то он может не отражать первоначальныое заверенное содержимое. Руководства по реализации могут дополнительно ограничивать описательную часть и модель отображения документа. If the document is presented in a different order from that given above, it might not represent the original attested content. Implementation Guides may restrict document narrative and display behavior further.

XML Tools reference implementation включает в себя XSLT-преобразование, конвертирующее XML-документ в XHTML, готовый для показа в браузере. The XML Tools reference implementation includes a XSLT transform that converts an XML document into browser-ready XHTML.

В дополнение к базовым правилам оформления описательной части, которые должны соблюдаться, документ может ссылаться или содержать один или больше таблиц стилей, включающих дополнительные стили, применяемые к объединенным описательным частям. Это достигается объявлением ссылок на таблицы стилей в фиде: In addition to the basic style rules about Narratives, which must be followed, a document can reference or contain one or more stylesheets that contains additional styles that apply to the collated narrative. This is done by asserting stylesheet links on the feed:

<Bundle xmlns="http://hl7.org/fhir">
  <!-- metadata and type -->
  <link>
    <relation value="stylesheet"/>
    <url value="[uri]"/>
  </link>
</Bundle>

Этот url может быть абсолютной ссылкой на каскадную таблицу стилей или относительной ссылкой на бинарный ресурс, содержащий CSS-таблицу. Ссылки на таблицы стилей могут ссылаться только на CSS - другие формы таблиц стилей не допустимы. The url can be an absolute reference to a CSS stylesheet or a relative reference to a Binary resource that carries a CSS stylesheet. Stylesheet references can only refer to a CSS stylesheet - other forms of stylesheet are not acceptable.

В таблицах стилей СЛЕДУЕТ использовать относительные (внутренние) ссылки, поскольку просмотрищик может быть не в состоянии разрешить внешнее содержимое во время просмотра из-за технических проблем или локальной политики безопасности. Relative (internal) references SHOULD be used for stylesheets, because the viewer may be unable to resolve external content at the time of viewing, due to technical problems or local policy decisions.

Никакие используемые таблицы стилей НЕ ДОЛЖНЫ изменять представление так, чтобы при этом искажалось медицинское значение содержимого. Any stylesheet referenced or used SHALL NOT alter the presentation in such a way that it changes the clinical meaning of the content.

Если другое не указано в локальных торговых партнерских соглашениях, приложения, отображающие объединенную описательную часть, ДОЛЖНЫ использовать таблицы стилей, указанные в документе (см. security note). Сторонам, входящие в торговое соглашение, поступающим иначе, следует очень тщательно рассмотреть последствия, которые это действие будет иметь на их долгосрочную область действия обмена документом. Если стороны согласны использовать таблицы стилей, не содержащиеся в документе, тогда, возможно, они никогда не смогут совместно использовать свои документы безопасно в более широком контексте, таком как региональные или национальные EHR или глобальные персональные медицинские документы. Unless otherwise agreed in local trading partner agreements, applications displaying the collated narrative SHOULD use the stylesheets specified by the document (see security note). Parties entering into a trading agreement to do otherwise should consider the implications this action will have on their long-term scope for document exchange very carefully. If the parties agree to use stylesheets that are not contained in the document, then it may be that they will never be able to share their documents safely in a more general context, such as a regional or national EHR or a global personal health record.

Профили документов используются для описания документов конкретного назначения. Профили документов могут вводить правила о: Document profiles are used to describe documents for a particular purpose. Document profiles may make rules about:

  • Содержимом ресурса Composition, в том числе
  • Структуре разделов в композиции
  • Какие ресурсы должны быть включены в комплект наряду с ресурсами, на которые есть прямые ссылки в ресурсе Document

Приложениям следует рассмотреть публикацию Capability Statements, в которых указываются конкретные документы, которые они поддерживают. Документы могут ссылаться на профиль, которому они соответствуют, указывая идентификатора профиля в элементе Bundle.meta.profile - см. информацию по их использованию в разделе Теги профилей. Applications should consider publishing Capability Statements that identify particular documents they support. Documents can identify a profile that they conform to by placing a profile identifier in the Bundle.meta.profile element - see Profile Tags for a discussion of the utility of this.

Авторы/конструкторы и обработчики Клинических документов - люди или программное обеспечение - имеют обязательства, которым они должны соответствовать. The authors/constructors and processors of Clinical Documents, whether human or software, have obligations that they must satisfy.

Конструктор документа - это приложение, которое создает документ. Автор - это человек, организация или устройство, использующее конструктор для создания документа. Между собой, конструктор и автор могут создавать новые контент-ресурсы и/или делать сборки из уже существующих контент-ресурсов при выполнении своих задач. Также у них есть следующие обязанности: A document constructor is an application that creates a document. An author is a human, organization or device that uses the constructor to create a document. Between them, the constructor and the author may create new content resources and/or assemble already existing content resources while performing their tasks. They also have the following responsibilities:

  • Гарантировать, что документ ДОЛЖЕН содержать допустимую композицию, которая соответствует правилам, описанным здесь, и ссылается только на другие допустимые ресурсы.
  • Гарантировать, что содержимое документа ДОЛЖНО соответствовать всем объявленным Профилям (см. ниже).
  • Ручаться, что свидетели должным образом ознакомлены с представлением документа, который они заверяют.

Обработчик документа - это приложение и/или человек-пользователь, который получает документы и извлекает из них данные или принимает на их основе решения. Эти документы могут быть получены прямо из конструктора документов, доступного через систему управления документами или переадресованного третьей стороной. Обработчик документов обеспечивает гарантию того, что полученные документы обработаны и/или отображены в соответствии с данной спецификацией. Обработчик документов обязан гарантировать соблюдение следующих правил: A document processor is an application and/or human user that receives documents and extracts data from them or makes decisions because of them. The documents may be received directly from a document constructor, accessed via a document management system or forwarded by a third party. The document processor is responsible for ensuring that received documents are processed and/or rendered in accordance to this specification. A document processor has the obligation to assure that the following rules are followed:

  • При сохранении/передаче документа любой метод может быть использован, пока документ комплекта может быть (пере)собран с достаточной целостностью для подтверждения достоверности цифровой подписи.
  • При представлении описательной части документа ДОЛЖНЫ быть соблюдены правила, описанные выше.
  • Ресурсы или данные из документа могут быть извлечены в дополнительных целях, однако такие данных больше не рассматриваются как заверенные автором документа.
  • Показываются ли данные из документа пользователю, ДОЛЖЕН всегда быть способ для пользователей получить доступ к представлению оригинального документа.

In addition to these obligations, document receivers SHOULD carefully track the source of documents for new documents that supersede existing documents, particularly when the documents represent compositions that have been retracted. When documents have been replaced, they SHOULD either withdraw data extracted from superseded documents or warn users when they view the document or data taken from it.

Имеется несколько разных RESTful конечных точек, используемых при работе с документами. Использование различных конечных точек лучше всего описать, рассматривая последствия отправки сообщений на них: There are several different RESTful end-points used when working with documents. The use of the various end-points can best be described by considering the consequences of posting to them:

End-Point Тип содержимого Описание
[baseurl]/Bundle Document Bundle Работает так же, как и обычная точка взаимодействия для управления типом ресурса, но только с целыми комплектами (bundles) документов - т. е. операция чтения возвращает bundle, обновление получает bundle и поиск возвращает комплект комплектов (bundle of bundles). Отметьте, что если документы создаются командой POST с помощью операции create, то Bundle.id поменяется, а Bundle.identifier - нет. См. комментарий в разделе Serving Bundles using the RESTful API.
[baseurl]/Composition Composition Resource Обычная точка взаимодействия для управления ресурсами композиции. Она может использоваться во время комплектации документа, после разбиения документа на составные ресурсы или во время использования композиций отдельно от документов.
[baseurl]/Binary Document Bundle Просто сохраняет весь документ в виде последовательности байтов и по запросу возвращает точно эту самую последовательность. Нет способа обнаружить содержимое в конечной точке /Binary, поэтому обычно это ассоциируется с Document Reference, чтобы приложения могли найти и обработать документ, хотя это и не обязательно.
[baseurl] (например transaction) Document Bundle Игнорирует факт, что комплект - это документ, и обрабатывает все ресурсы, которые он содержит, как самостоятельные ресурсы. Клиентам НЕ СЛЕДУЕТ ожидать, что сервер, который получает документ, отправленный с помощью этого метода, будет в состоянии пересобрать документ точно. (Даже если сервер может пересобрать документ (см. ниже), нельзя ожидать, что результат будет в том же порядке и т. п. Соответственно, подпись документа, весьма вероятно, станет недействительной.

Примечание: Несмотря на то, что эти точки взаимодействия определены для использования с документоподобными ресурсами и комплектами документов, их использование не обязательно. Документы можно передавать между системами с помощью любого желаемого метода. Помимо перечисленных выше опций, серверы и/или спецификации могут вводить дополнительные операции для работы с документами. Note: While these end-points are defined for use with document-related resources and document bundles, it is not necessary to use them. Documents may be transferred between systems using any method desired. In addition, servers and/or specifications may define additional operations for handling documents beyond the options described above.

Клиент может запросить сервер сгенерировать полностью скомплектованный документ из ресурса composition. Более подробную информацию см. на странице Generate Document Operation. A client can ask a server to generate a fully bundled document from a composition resource. For details, see Generate Document Operation.