-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathhl7ehrsfm.ttl
3383 lines (3043 loc) · 356 KB
/
hl7ehrsfm.ttl
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
@base <http://hitontology.eu/ontology/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix hito: <> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix bb: <http://www.snik.eu/ontology/bb/> .
@prefix dbr: <http://dbpedia.org/resource/> .
@prefix wikipedia: <https://en.wikipedia.org/wiki/> .
hito:EhrSfm
a hito:Classification ;
rdfs:label "HL7 Electronic Health Record System Functional Model"@en ;
rdfs:member hito:EhrSfmFeatureCatalogue ;
rdfs:seeAlso <http://www.hl7.org/implement/standards/product_brief.cfm?product_id=528> ;
owl:versionInfo "2.1" .
hito:EhrSfmAccessHealthcareGuidance
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.7.1" ;
hito:subFeatureOf hito:EhrSfmSupportFutureCare ;
a hito:FeatureClassified ;
rdfs:comment "Provide pertinent information from available evidence-based knowledge, at the point of care, for use in healthcare decisions and care planning."@en ;
rdfs:label "Access Healthcare Guidance"@en ;
skos:altLabel "CPS.7.1 Access Healthcare Guidance"@en ;
skos:definition "The information available regarding disease, disease processes, diagnostic testing, pharmaceuticals, treatment patterns and all aspects of healthcare is constantly changing. The practitioner should be able to access a wide variety of sources that provide relevant, accurate information about any given subject. Examples of resources include, but are not limited to evidence on treatment of specific medical conditions, maintenance of wellness, drug or device trials, context-specific information available through online journals, printed resources such as books and specialty organizations resources. For example, when a condition is diagnosed the provider might be directed to relevant resources that give updated clinical research, useful pharmaceutical combinations, surgical techniques, products or other information useful in the management of the specific condition under consideration."@en .
hito:EhrSfmAcknowledgeamendOtherProviderDocumentation
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.3.5" ;
hito:subFeatureOf hito:EhrSfmManageClinicalDocumentation ;
a hito:FeatureClassified ;
rdfs:comment "Review and indicate or amend other caregiver notes as permitted."@en ;
rdfs:label "Acknowledge/Amend Other Provider Documentation"@en ;
skos:altLabel "CP.3.5 Acknowledge/Amend Other Provider Documentation"@en ;
skos:definition "Scan/review notes from physicians, nurses, technicians and other members of the health care team (e.g., Respiratory Therapist, Physical Therapist). Annotate for disparities, make additions/amendments and import when desired and permitted."@en .
hito:EhrSfmAcknowledgmentsOfClinicallySignificantReportChangesClinicalAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.4.2" ;
hito:subFeatureOf hito:EhrSfmClinicalAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track acknowledgement of clinically significant report changes."@en ;
rdfs:label "Acknowledgments of Clinically Significant Report Changes Clinical Audit Trigger"@en ;
skos:altLabel "TI.2.1.4.2 Acknowledgments of Clinically Significant Report Changes Clinical Audit Trigger"@en ;
skos:definition "Capture acknowledgement of clinically significant report changes, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmAdHocQueryAndRendering
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.9.5" ;
hito:subFeatureOf hito:EhrSfmSupportCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:comment "Provide support for ad hoc query and report generation using tools internal or external to the system. Present customized views and summarized information from a patient's comprehensive EHR subject to jurisdictional laws and organizational policies related to privacy and confidentiality. The view may be arranged chronologically, by problem, or other parameters, and may be filtered or sorted."@en ;
rdfs:label "Ad Hoc Query and Rendering"@en ;
skos:altLabel "CPS.9.5 Ad Hoc Query and Rendering"@en ;
skos:definition "Providers and administrators need to respond quickly to new requirements for data measurement and analysis. This may be as a result of new regulatory requirements or internal requirements. This requires that users be able to define their own query parameters and retain them. The data may be found in both structured and unstructured data. Providers and administrators also need to query for the absence of specific clinical or administrative data. For example, the Quality Control department may be reviewing whether or not the protocol for management of Diabetes Mellitus is being followed. If the protocol calls for fasting blood sugars every 3 months at minimum, the investigator might need to run an across-patient query locating patients with diabetes who do not show an FBS result within the last 3 months. Emergency Department benchmarking reports - Key point of time include arrival time; treatment area entrance time, MD contact time; decision to admit, discharge or transfer time; and departure (left ED) time. Important intervals include, but are not limited to the “door to doctor time”, “doctor to diction time”, “admission to bed availability or departure” as well as overall length of stayA key feature of an electronic health record is its ability to support the delivery of care by enabling prior information to be found and meaningfully displayed. EHR systems should facilitate search, filtering (e.g., filtering by key word, tagged data, or diagnosis), summarization, and presentation of available data needed for patient care. Systems should enable views to be customized, for example, specific data may be organized chronologically, by clinical category, by consultant, depending on need. The views may be arranged chronologically, by problem, or other parameters, and may be filtered or sorted. Jurisdictional laws and organizational policies that prohibit certain users from accessing certain patient information must be supported."@en .
hito:EhrSfmAdministrationSupport
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS" ;
a hito:FeatureClassified ;
rdfs:label "Administration Support"@en ;
skos:altLabel "AS Administration Support"@en .
hito:EhrSfmAmendRecordEntryContent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.2" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Amend content of a Record Entry (1 instance)"@en ;
rdfs:label "Amend Record Entry Content"@en ;
skos:altLabel "RI.1.1.2 Amend Record Entry Content"@en ;
skos:definition "Occurs when Record Entry content is modified (from its original or previously retained state) – typically upon conclusion of an Action, to correct, update or complete content.- Amended Record Entry content is the responsibility of authorized amendment Author(s).- The amendment becomes part of the Act Record revision history, where the original content and any previous amendments are retained without alteration.- After amendment, the System is responsible for retention of the Record Entry and its revision history.- An Audit Trigger is initiated to track Record Entry amendment.Reference: ISO 21089, Section 12.3.2"@en .
hito:EhrSfmApplicationInterchangeStandards
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.5.1.1" ;
hito:subFeatureOf hito:EhrSfmApplicationStructuredMessageAndStructuredDocumentInterchangeStandards ;
a hito:FeatureClassified ;
rdfs:comment "Support the ability to operate seamlessly with other systems by using applications, and/or structured messages and documents that adhere to interchange standards."@en ;
rdfs:label "Application Interchange Standards"@en ;
skos:altLabel "TI.5.1.1 Application Interchange Standards"@en ;
skos:definition "Placeholder - Not Defined at this time"@en .
hito:EhrSfmApplicationStructuredMessageAndStructuredDocumentInterchangeStandards
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.5.1" ;
hito:subFeatureOf hito:EhrSfmStandardsbasedInteroperability ;
a hito:FeatureClassified ;
rdfs:comment "Support an EHR system's ability to operate seamlessly with systems that adhere to recognized application interchange standards. These systems include other EHR systems, subcomponents of an EHR system, or other (authorized, non-EHR) systems."@en ;
rdfs:label "Application, Structured- Message, and Structured- Document Interchange Standards"@en ;
skos:altLabel "TI.5.1 Application, Structured- Message, and Structured- Document Interchange Standards"@en ;
skos:definition "Since a health care organization typically has various external and internal interoperability requirements, it must use a set of corresponding interoperability or interchange standards that will meet its connectivity and information structure, format, and semantic requirements. Information should be exchanged -- and applications should provide functionality -- in a manner that appears to be seamless to the user. To be specific, if data is received from an external source that requires a user to manually copy-and-paste that data into multiple parts of the system, the exchange is not considered to be \"seamless\". Examples of standards-based EHR information content and exchange methods include: standards-based data extracts, standards-based messages, standards-based documents (e.g., HL7 Clinical Document Architecture (CDA) documents), standards-based healthcare transactions, and standards-based images (e.g., Digital Imaging and Communication in Medicine (DICOM) documents). Support for multiple interaction modes is needed to respond to differing levels of immediacy and types of exchange. For example, messaging is effective for many near-real time, asynchronous data exchange scenarios but may not be appropriate if the end-user is requesting an immediate response from a remote application. A variety of interaction modes are typically supported such as: - Unsolicited Notifications (e.g., Adam Everyman has arrived at the clinic for his scheduled appointment); - Query/Response (e.g., Query: Is Adam Everyman known to the system? Response: Yes, Adam's medical record number is 12345678); - Service Request and Response (e.g., Request: Laboratory Order for “Fasting Blood Sugar”. Response: the results of the test); - Information Interchange between organizations (e.g., in a regional health exchange or in a national health system); - Structured/discrete clinical documents (e.g., a structured clinical note); - Unstructured clinical document (e.g., dictated surgical note). Standard terminology is a fundamental part of interoperability and is described in section TI.4. Using a formal explicit information model further optimizes interoperability. An example of an information model is the HL7 Reference Information Model (RIM). Organizations typically need to deal with more than one information model and may need to develop a mapping between information models, a metamodel (that helps to explain and organize the various information models), or both."@en .
hito:EhrSfmArchiveRecordEntries
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.14" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Archive Record Entries (1 or more instances)"@en ;
rdfs:label "Archive Record Entries"@en ;
skos:altLabel "RI.1.1.14 Archive Record Entries"@en ;
skos:definition "Occurs when Record Entries are archived – typically to off-line (less readily available) storage media.- Archival of Record Entries may be initiated by User command.- Archival of Record Entries is the responsibility of the System – which invokes relevant rules.-An Audit Trigger is initiated to track Record Entry archival.Reference: ISO 21089, Section 12.10."@en .
hito:EhrSfmAttestRecordEntryContent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.4" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Attest to content of Record Entry (1 instance)"@en ;
rdfs:label "Attest Record Entry Content"@en ;
skos:altLabel "RI.1.1.4 Attest Record Entry Content"@en ;
skos:definition "Occurs when Record Entry content is attested for accuracy and completeness – typically during/after conclusion of an Action.- Attested Record Entry content is the responsibility of Attesting Author. The Attesting Author may be someone other than the originating Author, i.e., a supervisor, proctor, preceptor or other designated individual.- An Audit Trigger is initiated to track Record Entry attestation.The purpose of attestation is to show authorship and assign responsibility for an act, event, condition, opinion, E233 or diagnosis. Every Record Entry must be identified with the author and should not be made or signed by someone other than the author unless they have authority to do so. For example, a resident may author Record Entry content but the person taking legal authority for the content is the “attester” – both individuals should be identified. (Note: A transcriptionist may transcribe an author's notes and a senior clinician may attest to the accuracy of another's statement of events.)- Author: All users who create or contribute content and have a role in the development of a Record Entry. Some entries may be created by an author whose role is a student, transcriber or scribe. -Attester: A user who takes legal authority for Record Entry content. The attester is often the same as the author, but they may also be an individual with authority to take responsibility for Record Entry content created in whole or in part by another author(s) (e.g., student, scribe, transcriptionist).Reference: ISO 21089, Section 12.2.2."@en .
hito:EhrSfmAudit
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2" ;
hito:subFeatureOf hito:EhrSfmTrustInfrastructure ;
a hito:FeatureClassified ;
rdfs:comment "Audit Key Record, Security, System and Clinical Events"@en ;
rdfs:label "Audit"@en ;
skos:altLabel "TI.2 Audit"@en ;
skos:definition "EHR Systems have built in audit triggers to capture key events in real-time, including events related to record management, security, system operations or performance or clinical situations.Event details, including key metadata (who, what, when, where), are captured in an Audit Log.Audit Review functions allow various methods of critical event notification as well as routine log review.Audit functions implement requirements according to scope of practice, organizational policy, and jurisdictional law."@en .
hito:EhrSfmAuditLogIndelibility
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.2.1" ;
hito:subFeatureOf hito:EhrSfmAuditLogManagement ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Log Indelibility"@en ;
rdfs:label "Audit Log Indelibility"@en ;
skos:altLabel "TI.2.2.1 Audit Log Indelibility"@en ;
skos:definition "Audit logs must be maintained in a persistent and indelible form according to scope of practice, organizational policy, and jurisdictional law."@en .
hito:EhrSfmAuditLogManagement
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.2" ;
hito:subFeatureOf hito:EhrSfmAudit ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Log"@en ;
rdfs:label "Audit Log Management"@en ;
skos:altLabel "TI.2.2 Audit Log Management"@en ;
skos:definition "Audit Triggers create Audit Log entries. Audit Log entries are typically managed as persistent evidence of events occurring over time, including events pertaining to record management, security, system operations and performance, key clinical situations.Audit log entries capture event details, including key metadata (who, what, when, where).Audit log functions fulfill log maintenance and persistence requirements according to scope of practice, organizational policy, and jurisdictional law."@en .
hito:EhrSfmAuditNotificationAndReview
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.3" ;
hito:subFeatureOf hito:EhrSfmAudit ;
a hito:FeatureClassified ;
rdfs:comment "Notify of Audit Events, Review Audit Log"@en ;
rdfs:label "Audit Notification and Review"@en ;
skos:altLabel "TI.2.3 Audit Notification and Review"@en ;
skos:definition "EHR system functions allow various methods of critical event notification (from audit triggers) as well as routine log review.Audit log notification and review functions implement requirements according to scope of practice, organizational policy, and jurisdictional law."@en .
hito:EhrSfmAuditTriggers
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1" ;
hito:subFeatureOf hito:EhrSfmAudit ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Triggers"@en ;
rdfs:label "Audit Triggers"@en ;
skos:altLabel "TI.2.1 Audit Triggers"@en ;
skos:definition "EHR Systems have built in audit triggers to capture key events in real-time. Audit triggers signal key:- Record management and lifecycle events;- Security events related to system and data safeguards, both routine and exceptional;- System events related to performance and operations, both routine and exceptional.- Clinical events with special log requirements."@en .
hito:EhrSfmBackUpCompletedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.4" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track back-up completed event."@en ;
rdfs:label "Back Up Completed System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.4 Back Up Completed System Audit Trigger"@en ;
skos:definition "Capture back-up completed event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBackUpRecoveryCompletedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.6" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track back-up recovery completed event."@en ;
rdfs:label "Back Up Recovery Completed System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.6 Back Up Recovery Completed System Audit Trigger"@en ;
skos:definition "Capture back-up recovery completed event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBackUpRecoveryStartedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.5" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track back-up recovery started event."@en ;
rdfs:label "Back Up Recovery Started System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.5 Back Up Recovery Started System Audit Trigger"@en ;
skos:definition "Capture back-up recovery started event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBackUpStartedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.3" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track back-up started event."@en ;
rdfs:label "Back Up Started System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.3 Back Up Started System Audit Trigger"@en ;
skos:definition "Capture back-up started event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBatchJobCompletedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.8" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track batch job completed event."@en ;
rdfs:label "Batch Job Completed System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.8 Batch Job Completed System Audit Trigger"@en ;
skos:definition "Capture batch job completed event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBatchJobStartedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.7" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track batch job started event."@en ;
rdfs:label "Batch Job Started System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.7 Batch Job Started System Audit Trigger"@en ;
skos:definition "Capture system batch job started event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmBusinessRulesManagement
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.6" ;
hito:subFeatureOf hito:EhrSfmTrustInfrastructure ;
a hito:FeatureClassified ;
rdfs:comment "Manage the ability to create, update, delete, view, and version business rules including institutional preferences. Apply business rules from necessary points within an EHR-S to control system behavior. An EHR-S audits changes made to business rules, as well as compliance to and overrides of applied business rules."@en ;
rdfs:label "Business Rules Management"@en ;
skos:altLabel "TI.6 Business Rules Management"@en ;
skos:definition "EHR-S business rule implementation functions include decision support, diagnostic support, workflow control, and access privileges, as well as system and user defaults and preferences. An EHR-S supports the ability of providers and institutions to customize decision support components such as triggers, rules, or algorithms, as well as the wording of alerts and advice to meet realm specific requirements and preferences."@en .
hito:EhrSfmCaptureGuidelinesAndStandardsFromExternalSources
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.3.7" ;
hito:subFeatureOf hito:EhrSfmSupportClinicalDocumentation ;
a hito:FeatureClassified ;
rdfs:comment "Capture practice guidance from a variety of “trusted” external sources."@en ;
rdfs:label "Capture Guidelines and Standards from External Sources"@en ;
skos:altLabel "CPS.3.7 Capture Guidelines and Standards from External Sources"@en ;
skos:definition "Capture and import information provided by external health care organizations as relates to clinical practice guidelines (CPGs). External healthcare organizations in this function include, but are not limited to Patient management systems, Healthcare delivery organizations, Population health/surveillance organizations (e.g., local, regional, national and global Public Health services, PAHO, WHO), and professional, governmental, or industrial healthcare optimization initiatives."@en .
hito:EhrSfmCaptureHealthServiceReportInformation
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.9.2" ;
hito:subFeatureOf hito:EhrSfmManageCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:comment "Support the creation of health service reports to authorized health entities that a provider may be required to generate (e.g., the creation of an oncologist's report that must be submitted to a national cancer registry)."@en ;
rdfs:label "Capture Health Service Report Information"@en ;
skos:altLabel "CP.9.2 Capture Health Service Report Information"@en ;
skos:definition "Providers are prompted to collect sufficient information in the course of care to avoid duplicate, retrospective or other additional data entry as part of supporting health management programs and reporting, for example public health, such as notifiable condition reports, immunization, cancer registry and discharge data."@en .
hito:EhrSfmCaptureQuickRegistration
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.1.3" ;
hito:subFeatureOf hito:EhrSfmRecordManagement ;
a hito:FeatureClassified ;
rdfs:comment "Capture a registration, either directly entered or received from an external system, without complete supporting demographics, in order to facilitate patient care before the full registration is complete."@en ;
rdfs:label "Capture Quick Registration"@en ;
skos:altLabel "CPS.1.3 Capture Quick Registration"@en ;
skos:definition "The registration process, including the verification of full demographics data, insurance, contact information, etc. is frequently time consuming. To facilitate patient care in emergency situations, the system must be able to register a patient with minimal information in a time critical manner. Examples of situations when this might be necessary include when a patient presents with acute myocardial infarction, a disaster response, or a mass casualty event.After care is given during an emergent situation, records are often incomplete or invalid. Such records may need to be completed and validated. Afterwards, those records may need to be harmonized. For example, the records of \"John Doe1; approximate age is 30\" may need to be matched with existing records for \"Henry Smith; age 28\"."@en .
hito:EhrSfmCaptureReferralRequest
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.1.4" ;
hito:subFeatureOf hito:EhrSfmRecordManagement ;
a hito:FeatureClassified ;
rdfs:comment "Enable the receipt and processing of referrals from care providers or healthcare organizations, including clinical and administrative details of the referral, and consents and authorizations for disclosures as required."@en ;
rdfs:label "Capture Referral Request"@en ;
skos:altLabel "CPS.1.4 Capture Referral Request"@en ;
skos:definition "Incoming referrals may be from physicians' offices, specialists, clinics, Emergency Medical Services (EMS), transfers from other hospitals or emergency departments, nursing homes, etc. Referrals may be received electronically (i.e. e-Referrals); or may be received non-electronically. If non-electronic, the system needs to allow the user to capture the referral information and manage referral request. If the system supports e-Referrals, then the system will also need to support additional functionality to manage the receipt of the referral request. When a system receives a referral request the request must be validated against established criteria to determine if it meets the recipient’s requirements and is appropriate. Referrals may be received for patients who do not previously exist in the recipient system and the system must allow for the ability to triage the request and respond to the requestor. If appropriate the system should allow for the creation of a patient record including the capture of clinical and administrative information received with the referral request. The management of information on patients who are inbound to the care setting is an important component of information management. Data must be easily accessible, centrally retrievable, updatable, transportable and reusable. Clinical data from provider to provider is essential to quality-coordinated care for patients referred to the care setting. Knowledge of patients who are expected to arrive helps both care setting and administrative staff plan resource use in real time."@en .
hito:EhrSfmCareProvision
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP" ;
a hito:FeatureClassified ;
rdfs:label "Care Provision"@en ;
skos:altLabel "CP Care Provision"@en .
hito:EhrSfmCareProvisionSupport
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS" ;
hito:subFeatureOf hito:EhrSfmManageCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:label "Care Provision Support"@en ;
skos:altLabel "CPS Care Provision Support"@en .
hito:EhrSfmClinicalAlertsClinicalAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.4.1" ;
hito:subFeatureOf hito:EhrSfmClinicalAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track clinical alerts."@en ;
rdfs:label "Clinical Alerts Clinical Audit Trigger"@en ;
skos:altLabel "TI.2.1.4.1 Clinical Alerts Clinical Audit Trigger"@en ;
skos:definition "Capture clinical alerts, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmClinicalAuditTriggers
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.4" ;
hito:subFeatureOf hito:EhrSfmAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Clinical Audit Triggers"@en ;
rdfs:label "Clinical Audit Triggers"@en ;
skos:altLabel "TI.2.1.4 Clinical Audit Triggers"@en ;
skos:definition "Clinical Audit Triggers are designed to capture certain clinical events, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmClinicalCommunicationManagementAndSupport
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.9.1" ;
hito:subFeatureOf hito:EhrSfmSupportCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:comment "Support exchange of information between participants in patient-centered care as needed, and the appropriate documentation of such exchanges. Support secure communication to protect the privacy of information as required by jurisdictional law."@en ;
rdfs:label "Clinical Communication Management and Support"@en ;
skos:altLabel "CPS.9.1 Clinical Communication Management and Support"@en ;
skos:definition "Healthcare requires secure communications among various participant in the patient's circle of care: patients, doctors, nurses, chronic disease care managers, public health authorities, pharmacies, laboratories, payers, consultants etc. An effective EHRS supports communication across all relevant participants, reduces the overhead and costs of healthcare-related communications, and provides automatic tracking and reporting. The list of communication participants is determined by the care setting and may change over time.Because of concerns about scalability of the specification over time, communication participants for all care settings or across care settings are not enumerated here because it would limit the possibilities available to each care setting and implementation. However, communication between providers and between patients and providers will be supported in all appropriate care settings and across care settings. Implementation of the EHRS enables new and more effective channels of communication, significantly improving efficiency and patient care. The communication functions of the EHRS changes the way participants collaborate and distribute the work of patient care."@en .
hito:EhrSfmClinicalDecisionSupportSystemGuidelinesUpdates
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.3.9" ;
hito:subFeatureOf hito:EhrSfmSupportClinicalDocumentation ;
a hito:FeatureClassified ;
rdfs:comment "Capture and maintain updates of clinical decision support system guidelines and associated reference material."@en ;
rdfs:label "Clinical Decision Support System Guidelines Updates"@en ;
skos:altLabel "CPS.3.9 Clinical Decision Support System Guidelines Updates"@en ;
skos:definition "System content such as discharge instructions, clinical guidelines, formularies, and other knowledge bases should be capable of being maintained and updated, independent of a particular encounter. Clinical decision support rules may be applied to the system using a manual process. As standards are developed to represent these rules, an automated update will be recommended. Any process to update decision support rules should include the verification of the appropriateness of the rules to the system. This may include but not be limited to authenticity of the source, the currency of the version, and any necessary approvals before updates can take place."@en .
hito:EhrSfmClinicalTaskAssignmentAndRoutingForMedicationManagementAdministration
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.5.2" ;
hito:subFeatureOf hito:EhrSfmManageClinicalWorkflowTasking ;
a hito:FeatureClassified ;
rdfs:comment "Assignment, delegation, and/or transmission of tasks for Medication Orders and Prescription Management."@en ;
rdfs:label "Clinical Task Assignment and Routing for Medication Management & Administration"@en ;
skos:altLabel "AS.5.2 Clinical Task Assignment and Routing for Medication Management & Administration"@en ;
skos:definition "There are tasks that are specific to prescription management. An example of a system-triggered task is when a medication defined as for continuous use runs out, a notification task should be initiated for evaluation of the need to renew or not. Quality care implies consideration of medication continuation or renewal in light of various patient and visit factors . This requires also that the relevant information is presented to the clinician in an effective manner. The decision by the clinician must then be captured in an efficient manner and actioned by the system through task assignment and communication. Presentation of tasks to be carried out needs to be in a manner that facilitates their execution and management and needs to correspond to user preferences. For example, the list could be ordered by priority or by pharmacy phone number for efficiency."@en .
hito:EhrSfmClinicalTaskCreationAssignmentAndRouting
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.5.1" ;
hito:subFeatureOf hito:EhrSfmManageClinicalWorkflowTasking ;
a hito:FeatureClassified ;
rdfs:comment "Creation, assignment, delegation, and/or transmission of tasks to the appropriate parties."@en ;
rdfs:label "Clinical Task Creation, Assignment and Routing"@en ;
skos:altLabel "AS.5.1 Clinical Task Creation, Assignment and Routing"@en ;
skos:definition "A \"Task\" is a specific piece of work or duty that is assigned to a person or entity. A task often needs to be accomplished within a defined period of time or by a deadline. Tasks are often managed by an activity (or project) tracking mechanism (e.g., as part of an automated business rule process). Tasks are determined by the specific needs of patients and practitioners in a care setting. Task creation may be automated, where appropriate. An example of a system-triggered task is when laboratory results are received electronically; a task to review the result is automatically generated and assigned to a responsible party. Tasks are at all times assigned to at least one user or role for disposition. Whether the task is assignable and to whom the task can be assigned will be determined by the specific needs of practitioners in a care setting. Task-assignment lists help users prioritize and complete assigned tasks. For example, after receiving communication (e.g., a phone call or e-mail) from a patient, the triage nurse routes or assigns a task to return the patient's call to the physician who is on call physician. Another example is for a urinalysis, the nurse routes or assigns a task to clinical staff to collect a urine specimen, and for the results to be routed to the responsible physician and person ordering the test. Task creation and assignment may be automated, where appropriate. An example is when (International Normalized Ratio) INR results are received they should be automatically routed and assigned to the staff person in the clinic responsible for managing all of the patients that are having INR tests done. Task assignment ensures that all tasks are disposed of by the appropriate person or role and allows efficient interaction of entities in the care process. When a task is assigned to more than one individual or role, an indication is required to show whether the task must be completed by all individuals/roles or if only one completion suffice."@en .
hito:EhrSfmClinicalTaskLinking
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.5.3" ;
hito:subFeatureOf hito:EhrSfmManageClinicalWorkflowTasking ;
a hito:FeatureClassified ;
rdfs:comment "Linkage of tasks to EHR components, patients, and/or a relevant part of the electronic health record."@en ;
rdfs:label "Clinical Task Linking"@en ;
skos:altLabel "AS.5.3 Clinical Task Linking"@en ;
skos:definition "Clinical tasks must include information or provide an electronic link to information that is required to complete the task. There is a need to create the appropriate links and, then, to have the system automatically present the information that was linked. For example, this may include a patient location in a facility, a patient’s, and/or family's contact information, or a link to new laboratory results in the patient’s EHR. Other example: the linkage of prescription task to the appropriate patient care plan to facilitate follow-up actions; a task to take weights links to the ‘Weights and Vitals’ screen to record the result; a task to complete a fall assessment links to the fall assessment form to be completed. An example of a well defined task is \"Dr. Jones must review Mr. Smith's blood work results.\" Efficient workflow is facilitated by navigating to the appropriate area of the record to ensure that the appropriate test result for the correct patient is reviewed."@en .
hito:EhrSfmClinicalTaskStatusTracking
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.5.4" ;
hito:subFeatureOf hito:EhrSfmManageClinicalWorkflowTasking ;
a hito:FeatureClassified ;
rdfs:comment "Track tasks to facilitate monitoring for timely and appropriate completion of each task."@en ;
rdfs:label "Clinical Task Status Tracking"@en ;
skos:altLabel "AS.5.4 Clinical Task Status Tracking"@en ;
skos:definition "In order to reduce the risk of errors during the care process due to missed tasks, the provider is able to view the status of each task (e.g., unassigned, on hold, started, performed, canceled, denied, and resolved) and current work lists, lists of unassigned tasks or undisposed tasks, or of other tasks where a risk of omission exists. The timeliness of certain tasks can be tracked, or reports generated, in accordance with relevant law and accreditation standards. For example, a provider is able to create a report that shows tests that have not yet been performed such as urine specimen obtained, blood work drawn, etc. Another example is that of an electronic prescribing system that would track when a refill request or prescription change is received, who it has been assigned to, the action performed, and when it was completed."@en .
hito:EhrSfmCommunicationWithPersonalHealthRecordSystem
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.8.6" ;
hito:subFeatureOf hito:EhrSfmSupportPatientEducationCommunication ;
a hito:FeatureClassified ;
rdfs:comment "Enable and manage communication between EHR Systems and PHR Systems."@en ;
rdfs:label "Communication with Personal Health Record System"@en ;
skos:altLabel "CPS.8.6 Communication with Personal Health Record System"@en ;
skos:definition "With the increasing use of Personal Health Record systems, it is necessary for the EHR-S to appropriately communicate with the PHR to both capture patient information from the PHR and transmit relevant portions of the EHR patient record to the PHR to support patient self care."@en .
hito:EhrSfmConductAssessments
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.3.1" ;
hito:subFeatureOf hito:EhrSfmManageClinicalDocumentation ;
a hito:FeatureClassified ;
rdfs:comment "Create and maintain assessment information."@en ;
rdfs:label "Conduct Assessments"@en ;
skos:altLabel "CP.3.1 Conduct Assessments"@en ;
skos:definition "During an encounter with a patient, the provider will conduct an assessment that is germane to the age, gender, developmental or functional state, medical and behavioral condition of the patient, such as growth charts, developmental profiles, and disease specific assessments. Wherever possible, this assessment should follow industry standard protocols although, for example, an assessment for an infant will have different content than one for an elderly patient. When a specific assessment template does not exist, a new, locally-defined assessment can be created, using the format and data elements of similar assessments whenever possible. (NOTE: A new assessment may not necessarily be unique, since a facility may copy an assessment from another facility.)"@en .
hito:EhrSfmDataCorruptionSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.16" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track data corruption events."@en ;
rdfs:label "Data Corruption System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.16 Data Corruption System Audit Trigger"@en ;
skos:definition "Capture data corruption event, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmDatabaseBackupAndRecovery
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.8" ;
hito:subFeatureOf hito:EhrSfmTrustInfrastructure ;
a hito:FeatureClassified ;
rdfs:comment "Provide for the ability to backup and recover the EHR system."@en ;
rdfs:label "Database Backup and Recovery"@en ;
skos:altLabel "TI.8 Database Backup and Recovery"@en ;
skos:definition "To enable the preservation of the EHR database and it's data, functionality needs to be present to record a copy of the database and it's contents to offline media as well as the recovery of the system from a backup copy and resumption of normal system operation. The backup must preserve both data as well as database structure and definition information sufficient to recover a complete functional EHR system. Database components may include, but not be limited to application data, security credentials, log/audit files, and programs; ultimately all EHR components necessary to provide a full and complete operating environment. Finally, the backup must be capable of being used during recovery processing to restore an exact copy of the EHR system as of a particular instant in time. This is a requirement to be able to preserve logical consistency of information within the recovered EHR system.In providing for this capability the system may Include multiple backup, and/or redundancy solutions such as fail-over architecture, database journaling, transaction processing, etc.The backup and recovery function must address both physical system failure (i.e. failure of EHR system hardware) as well as logical system failure (e.g., database corruption).To support the requirement that the EHR system be available whenever it is needed within the design parameters of the system and provide reliability and redundancy of the EHR database and it's data, the backup function shall not impact user functionality or appreciably impact user performance.The backup function may include features which permit multiple processes and technologies to perform it's task. This may include multiple backup technologies such as tape, disk, cloud, etc. Also, multiple architectures such as redundancy, online, near-line and off-line media."@en .
hito:EhrSfmDeidentifiedDataRequestManagement
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "POP.8" ;
hito:subFeatureOf hito:EhrSfmPopulationHealthSupport ;
a hito:FeatureClassified ;
rdfs:comment "Provide patient data in a manner that meets applicable requirements for de-identification."@en ;
rdfs:label "De-Identified Data Request Management"@en ;
skos:altLabel "POP.8 De-Identified Data Request Management"@en ;
skos:definition "When an internal or external party requests patient data and that party requests de-identified data (or is not entitled to identified patient information, either by law or custom), the user can export the data in a fashion that meets the requirements for de identification in that locale or realm.An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review.A random re-identification key may be added to the data, to support re-identification for the purpose of alerting providers of potential patient safety issues. For example, if it is discovered that a patient is at risk for a major cardiac event, the provider could be notified of this risk, allowing the provider to identify the patient from the random key."@en .
hito:EhrSfmDeidentifyRecordEntries
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.10" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "De-identify content of Record Entries (1 or more instances)"@en ;
rdfs:label "De-identify Record Entries"@en ;
skos:altLabel "RI.1.1.10 De-identify Record Entries"@en ;
skos:definition "Occurs when Record Entry content is transformed into de-identified version.- De-identification of Record Entries may be initiated by User command.- De-identification of Record Entries is the responsibility of the System – which invokes relevant rules.- An Audit Trigger is initiated to track Record Entry de-identification.Reference: ISO 21089, Section 12.6.1."@en .
hito:EhrSfmDeprecateretractRecordEntries
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.17" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Deprecate/retract Record Entries as invalid (1 or more instances)"@en ;
rdfs:label "Deprecate/Retract Record Entries"@en ;
skos:altLabel "RI.1.1.17 Deprecate/Retract Record Entries"@en ;
skos:definition "Occurs when Record Entries are deprecated if found to be improperly identified or otherwise invalid.- Deprecation of Record Entries may be initiated by User command.- Deprecation of Record Entries is the responsibility of the System – which invokes relevant rules.- An Audit Trigger is initiated to track Record Entry Deprecation."@en .
hito:EhrSfmDestroyOrIdentifyRecordEntriesAsMissing
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.16" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Destroy or Identify Record Entries as Missing (1 or more instances)"@en ;
rdfs:label "Destroy or Identify Record Entries as Missing"@en ;
skos:altLabel "RI.1.1.16 Destroy or Identify Record Entries as Missing"@en ;
skos:definition "Occurs when Record Entries are destroyed or identified as missing.- Destruction typically occurs after conclusion of the legal retention period.- Destruction of Record Entries may be initiated by User command.- Destruction of Record Entries is the responsibility of the System – which invokes relevant rules.- An Audit Trigger is initiated to track Record Entry Destruction or Notation as Missing.Reference: ISO 21089, Section 12.11."@en .
hito:EhrSfmDisableDecisionSupportAlertsClinicalAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.4.3" ;
hito:subFeatureOf hito:EhrSfmClinicalAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track disabling of decision support alerts."@en ;
rdfs:label "Disable Decision Support Alerts Clinical Audit Trigger"@en ;
skos:altLabel "TI.2.1.4.3 Disable Decision Support Alerts Clinical Audit Trigger"@en ;
skos:definition "Capture disabling of decision support alerts, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmDiscloseRecordEntryContent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.7" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Disclose content of Record Entries"@en ;
rdfs:label "Disclose Record Entry Content"@en ;
skos:altLabel "RI.1.1.7 Disclose Record Entry Content"@en ;
skos:definition "Occurs when Record Entry content is disclosed according to scope of practice, organizational policy or jurisdictional law.- Disclosed Record Entry content is the responsibility of authorized User(s).- An Audit Trigger is initiated to track Record Entry content disclosures.Reference: ISO 21089, Section 12.5."@en .
hito:EhrSfmDonorManagementSupport
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "POP.5" ;
hito:subFeatureOf hito:EhrSfmPopulationHealthSupport ;
a hito:FeatureClassified ;
rdfs:comment "Manage population-based information regarding potential human-product donors, and/or recipients."@en ;
rdfs:label "Donor Management Support"@en ;
skos:altLabel "POP.5 Donor Management Support"@en ;
skos:definition "Population-based health risks often require the identification of potential donors and recipients (e.g., during a disaster, blood is often needed). Other population-based donors and recipients may need to be identified for items such as organs, eggs, sperm, or stem cells. The user can make this information available to internal and external donor matching agencies. A consent or authorization includes patient authorization for redisclosure of sensitive information to third parties (such as donor management)."@en .
hito:EhrSfmEmergencyAccessControl
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.1.3.1" ;
hito:subFeatureOf hito:EhrSfmManageRecordPendingState ;
a hito:FeatureClassified ;
rdfs:comment "Manage emergency access to EHR-S resources."@en ;
rdfs:label "Emergency Access Control"@en ;
skos:altLabel "TI.1.3.1 Emergency Access Control"@en ;
skos:definition "The intent of Emergency Access Control is to mitigate the potential for impeding the provision of care in an emergency situation in accordance with organizational policy.For example, emergency access may include: 1) Single record entry (e.g., single laboratory results, single document, single view); 2) Single patient; 3) Single login session, multiple patients; 4) Site mode allowing simultaneous emergency access to all users.Logging of a user’s activities should occur in the audit record/metadata. Reports of emergency access use for follow up are critical for compliance and monitoring."@en .
hito:EhrSfmEntityAccessControl
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.1.3" ;
hito:subFeatureOf hito:EhrSfmSecurity ;
a hito:FeatureClassified ;
rdfs:comment "Manage access to EHR-S resources."@en ;
rdfs:label "Entity Access Control"@en ;
skos:altLabel "TI.1.3 Entity Access Control"@en ;
skos:definition "To ensure access is controlled, an EHR-S must authenticate and check authorization of entities for appropriate operations."@en .
hito:EhrSfmEntityAuthentication
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.1.1" ;
hito:subFeatureOf hito:EhrSfmSecurity ;
a hito:FeatureClassified ;
rdfs:comment "Authenticate EHR-S users, and/or entities before allowing access."@en ;
rdfs:label "Entity Authentication"@en ;
skos:altLabel "TI.1.1 Entity Authentication"@en ;
skos:definition "All entities accessing the EHR-S are subject to authentication.Examples of entity authentication, with varying levels of authentication rigor, include: - username/password;- digital certificate;- secure token;- biometrics."@en .
hito:EhrSfmEntityAuthorization
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.1.2" ;
hito:subFeatureOf hito:EhrSfmSecurity ;
a hito:FeatureClassified ;
rdfs:comment "Manage set(s) of EHR-S access control permissions."@en ;
rdfs:label "Entity Authorization"@en ;
skos:altLabel "TI.1.2 Entity Authorization"@en ;
skos:definition "Entities are authorized to use components of an EHR-S in accordance with their scope of practice within local policy or legal jurisdiction. Authorization rules provide a proper framework for establishing access permissions and privileges for the use of an EHR system, based on user, role or context. A combination of these authorization categories may be applied to control access to EHRS resources (i.e., functions or data), including at the operating system level.- User based authorization refers to the permissions granted to access EHR-S resources based on the identity of an entity (e.g., user or software component). - Role based authorization refers to the permissions granted to access EHR-S resources based on the role of an entity. Examples of roles include: an application or device (tele-monitor or robotic); or a nurse, dietician, administrator, legal guardian, and auditor. - Context-based Authorization refers to the permissions granted to access EHR-S resources within a context, such as when a request occurs, explicit time, location, route of access, quality of authentication, work assignment, patient consents and authorization. See ISO 10181-3 Technical Framework for Access Control Standard. For example, an EHR-S might only allow supervising providers’ context authorization to attest to entries proposed by residents under their supervision."@en .
hito:EhrSfmEvidenceOfRecordEntryAmendmentEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.2.1" ;
hito:subFeatureOf hito:EhrSfmAmendRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Amendment Event"@en ;
rdfs:label "Evidence of Record Entry Amendment Event"@en ;
skos:altLabel "RI.1.1.2.1 Evidence of Record Entry Amendment Event"@en ;
skos:definition "Evidence of Record Entry Amendment Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryArchiveEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.14.1" ;
hito:subFeatureOf hito:EhrSfmArchiveRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Archive Event"@en ;
rdfs:label "Evidence of Record Entry Archive Event"@en ;
skos:altLabel "RI.1.1.14.1 Evidence of Record Entry Archive Event"@en ;
skos:definition "Evidence of Record Entry Archive Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryAttestationEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.4.1" ;
hito:subFeatureOf hito:EhrSfmAttestRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Attestation Event"@en ;
rdfs:label "Evidence of Record Entry Attestation Event"@en ;
skos:altLabel "RI.1.1.4.1 Evidence of Record Entry Attestation Event"@en ;
skos:definition "Evidence of Record Entry Attestation Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryDeidentificationEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.10.1" ;
hito:subFeatureOf hito:EhrSfmDeidentifyRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry De-Identification Event"@en ;
rdfs:label "Evidence of Record Entry De-Identification Event"@en ;
skos:altLabel "RI.1.1.10.1 Evidence of Record Entry De-Identification Event"@en ;
skos:definition "Evidence of Record Entry De-Identification Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryDeprecationretractionEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.17.1" ;
hito:subFeatureOf hito:EhrSfmDeprecateretractRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Deprecation/Retraction Event"@en ;
rdfs:label "Evidence of Record Entry Deprecation/Retraction Event"@en ;
skos:altLabel "RI.1.1.17.1 Evidence of Record Entry Deprecation/Retraction Event"@en ;
skos:definition "Evidence of Record Entry Deprecation/Retraction Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryDestructionEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.16.1" ;
hito:subFeatureOf hito:EhrSfmDestroyOrIdentifyRecordEntriesAsMissing ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Destruction Event"@en ;
rdfs:label "Evidence of Record Entry Destruction Event"@en ;
skos:altLabel "RI.1.1.16.1 Evidence of Record Entry Destruction Event"@en ;
skos:definition "Evidence of Record Entry Destruction Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryDisclosureEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.7.1" ;
hito:subFeatureOf hito:EhrSfmDiscloseRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Disclosure Event"@en ;
rdfs:label "Evidence of Record Entry Disclosure Event"@en ;
skos:altLabel "RI.1.1.7.1 Evidence of Record Entry Disclosure Event"@en ;
skos:definition "Evidence of Record Entry Disclosure Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryExtractionEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.13.1" ;
hito:subFeatureOf hito:EhrSfmExtractRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Extraction Event"@en ;
rdfs:label "Evidence of Record Entry Extraction Event"@en ;
skos:altLabel "RI.1.1.13.1 Evidence of Record Entry Extraction Event"@en ;
skos:definition "Evidence of Record Entry Extraction Events includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryLegalHoldEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.23.1" ;
hito:subFeatureOf hito:EhrSfmPlaceRecordEntriesOnLegalHold ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Legal Hold Event"@en ;
rdfs:label "Evidence of Record Entry Legal Hold Event"@en ;
skos:altLabel "RI.1.1.23.1 Evidence of Record Entry Legal Hold Event"@en ;
skos:definition "Evidence of Record Entry Legal Hold Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryLegalHoldRemovalEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.24.1" ;
hito:subFeatureOf hito:EhrSfmReleaseRecordEntriesFromLegalHold ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Legal Hold Removal Event"@en ;
rdfs:label "Evidence of Record Entry Legal Hold Removal Event"@en ;
skos:altLabel "RI.1.1.24.1 Evidence of Record Entry Legal Hold Removal Event"@en ;
skos:definition "Evidence of Record Entry Legal Hold Removal Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryLinkEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.21.1" ;
hito:subFeatureOf hito:EhrSfmLinkRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Link Event"@en ;
rdfs:label "Evidence of Record Entry Link Event"@en ;
skos:altLabel "RI.1.1.21.1 Evidence of Record Entry Link Event"@en ;
skos:definition "Evidence of Record Entry Link Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryMergeEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.19.1" ;
hito:subFeatureOf hito:EhrSfmMergeRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Merge Event"@en ;
rdfs:label "Evidence of Record Entry Merge Event"@en ;
skos:altLabel "RI.1.1.19.1 Evidence of Record Entry Merge Event"@en ;
skos:definition "Evidence of Record Entry Merge Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryOriginateretainEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.1.1" ;
hito:subFeatureOf hito:EhrSfmOriginateAndRetainRecordEntry ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Originate/Retain Event"@en ;
rdfs:label "Evidence of Record Entry Originate/Retain Event"@en ;
skos:altLabel "RI.1.1.1.1 Evidence of Record Entry Originate/Retain Event"@en ;
skos:definition "Evidence of Record Entry Originate/Retain Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryOutputreportEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.6.1" ;
hito:subFeatureOf hito:EhrSfmOutputreportRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Output/Report Event"@en ;
rdfs:label "Evidence of Record Entry Output/Report Event"@en ;
skos:altLabel "RI.1.1.6.1 Evidence of Record Entry Output/Report Event"@en ;
skos:definition "Evidence of Record Entry Output/Report Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryPseudomynizationEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.11.1" ;
hito:subFeatureOf hito:EhrSfmPseudomynizeRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Pseudomynization Event"@en ;
rdfs:label "Evidence of Record Entry Pseudomynization Event"@en ;
skos:altLabel "RI.1.1.11.1 Evidence of Record Entry Pseudomynization Event"@en ;
skos:definition "Evidence of Record Entry Pseudomynization Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryReactivationEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.18.1" ;
hito:subFeatureOf hito:EhrSfmReactivateRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Re-Activation Event"@en ;
rdfs:label "Evidence of Record Entry Re-Activation Event"@en ;
skos:altLabel "RI.1.1.18.1 Evidence of Record Entry Re-Activation Event"@en ;
skos:definition "Evidence of Record Entry Re-Activation Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryReceiveretainEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.9.1" ;
hito:subFeatureOf hito:EhrSfmReceiveAndRetainRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Receive/Retain Event"@en ;
rdfs:label "Evidence of Record Entry Receive/Retain Event"@en ;
skos:altLabel "RI.1.1.9.1 Evidence of Record Entry Receive/Retain Event"@en ;
skos:definition "Evidence of Record Entry Receive/Retain Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryReidentificationEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.12.1" ;
hito:subFeatureOf hito:EhrSfmReidentifyRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Re-Identification Event"@en ;
rdfs:label "Evidence of Record Entry Re-Identification Event"@en ;
skos:altLabel "RI.1.1.12.1 Evidence of Record Entry Re-Identification Event"@en ;
skos:definition "Evidence of Record Entry Re-Identification Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryRestoreEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.15.1" ;
hito:subFeatureOf hito:EhrSfmRestorePreviouslyArchivedRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Restore Event"@en ;
rdfs:label "Evidence of Record Entry Restore Event"@en ;
skos:altLabel "RI.1.1.15.1 Evidence of Record Entry Restore Event"@en ;
skos:definition "Evidence of Record Entry Restore Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryTranslateEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.3.1" ;
hito:subFeatureOf hito:EhrSfmTranslateRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Translate Event"@en ;
rdfs:label "Evidence of Record Entry Translate Event"@en ;
skos:altLabel "RI.1.1.3.1 Evidence of Record Entry Translate Event"@en ;
skos:definition "Evidence of Record Entry Translate Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryTransmitEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.8.1" ;
hito:subFeatureOf hito:EhrSfmTransmitRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Transmit Event"@en ;
rdfs:label "Evidence of Record Entry Transmit Event"@en ;
skos:altLabel "RI.1.1.8.1 Evidence of Record Entry Transmit Event"@en ;
skos:definition "Evidence of Record Entry Transmit Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryUnlinkEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.22.1" ;
hito:subFeatureOf hito:EhrSfmUnlinkRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Unlink Event"@en ;
rdfs:label "Evidence of Record Entry Unlink Event"@en ;
skos:altLabel "RI.1.1.22.1 Evidence of Record Entry Unlink Event"@en ;
skos:definition "Evidence of Record Entry Unlink Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryUnmergeEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.20.1" ;
hito:subFeatureOf hito:EhrSfmUnmergeRecordEntries ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry Unmerge Event"@en ;
rdfs:label "Evidence of Record Entry Unmerge Event"@en ;
skos:altLabel "RI.1.1.20.1 Evidence of Record Entry Unmerge Event"@en ;
skos:definition "Evidence of Record Entry Unmerge Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmEvidenceOfRecordEntryViewaccessEvent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.5.1" ;
hito:subFeatureOf hito:EhrSfmViewaccessRecordEntryContent ;
a hito:FeatureClassified ;
rdfs:comment "Maintain Evidence of Record Entry View/Access Event"@en ;
rdfs:label "Evidence of Record Entry View/Access Event"@en ;
skos:altLabel "RI.1.1.5.1 Evidence of Record Entry View/Access Event"@en ;
skos:definition "Evidence of Record Entry View/Access Event includes key metadata, ensures health record integrity (and trust) and enables record audit."@en .
hito:EhrSfmExtractRecordEntryContent
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.13" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Extract Record Entry content to produce subsets, derivations, summaries or aggregations (Multiple instances)"@en ;
rdfs:label "Extract Record Entry Content"@en ;
skos:altLabel "RI.1.1.13 Extract Record Entry Content"@en ;
skos:definition "Occurs when Record Entry content is extracted to render subsets, derivations, summaries or aggregations. - Extraction of Record Entry content may be initiated by User command, and/or rules-based algorithm. - Extraction of Record Entry content is the responsibility of the System – which invokes relevant rules. - An Audit Trigger is initiated to track Record Entry content extraction. Reference: ISO 21089, Section 12.7. An EHR-S enables an authorized user, such as a clinician, to access and aggregate the distributed information, which corresponds to the health record or records that are needed for viewing, reporting, disclosure, etc. An EHR-S must support data extraction operations across the complete data set that constitutes the health record of an individual and provide an output that fully chronicles the healthcare process. Data extractions are used as input to patient care coordination between facilities, organizations and settings. In addition, data extractions can be used for administrative, financial, research, quality analysis, public health purposes, and to enable re-creation of copies for importing into different EHR applications and enable the archiving of patients' data. Data may be extracted in order to meet analysis and reporting requirements. The extracted data may require use of more than one application and it may be pre-processed (for example, by being de-identified) before transmission. Data extractions may be used to exchange data and provide reports for primary and ancillary purposes."@en .
hito:EhrSfmExtraordinaryUserAccessBreakTheGlassSecurityAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.2.8" ;
hito:subFeatureOf hito:EhrSfmSecurityAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track extraordinary user access (break the glass)."@en ;
rdfs:label "Extraordinary User Access (Break the Glass) Security Audit Trigger"@en ;
skos:altLabel "TI.2.1.2.8 Extraordinary User Access (Break the Glass) Security Audit Trigger"@en ;
skos:definition "Capture extraordinary user access (break the glass), both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmFeatureCatalogue
a hito:FeatureCatalogue ;
rdfs:comment "HL7 Electronic Health Record System Functional Model Feature Catalogue"@en ;
rdfs:label "HL7 EHR-S FM Feature Catalogue"@en ;
rdfs:seeAlso <http://www.hl7.org/implement/standards/product_brief.cfm?product_id=528> .
hito:EhrSfmGenerateRecordAndDistributePatientSpecificInstructions
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.8.1" ;
hito:subFeatureOf hito:EhrSfmManagePatientEducationCommunication ;
a hito:FeatureClassified ;
rdfs:comment "Generate and record patient-specific instructions related to pre- and post-procedural and post-treatment/discharge requirements."@en ;
rdfs:label "Generate, Record and Distribute Patient- Specific Instructions"@en ;
skos:altLabel "CP.8.1 Generate, Record and Distribute Patient- Specific Instructions"@en ;
skos:definition "When a patient is scheduled for a test, procedure, or discharge, specific instructions about diet, clothing, transportation assistance, convalescence, follow-up with physician, etc., may be generated and recorded, including the timing relative to the scheduled event. In an outpatient scenario, similar instructions for post-diagnosis, and/or post-treatment needs may also be generated and recorded (e.g., exercise instructions for low back pain, wound or burn care)."@en .
hito:EhrSfmHealthRecordOutput
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.9.3" ;
hito:subFeatureOf hito:EhrSfmSupportCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:comment "Support the definition of the formal health record, a partial record for referral purposes, or sets of records for other necessary disclosure purposes."@en ;
rdfs:label "Health Record Output"@en ;
skos:altLabel "CPS.9.3 Health Record Output"@en ;
skos:definition "Provide hardcopy and electronic output that fully chronicles the healthcare process, supports selection of specific sections of the health record, and allows healthcare organizations to define the report, and/or documents that will comprise the formal health record for disclosure purposes. A mechanism should be provided for both chronological and specified record element output. This may include defined reporting groups (i.e. print sets). For example Print Set A = Patient Demographics, History & Physical, Consultation Reports, and Discharge Summaries. Print Set B = all information created by one caregiver. Print Set C = all information from a specified encounter. An auditable record of these requests and associated exports may be maintained by the system. This record could be implemented in any way that would allow the who, what, why and when of a request and export to be recoverable for review. The system has the capability of providing a report or accounting of disclosures by patient that meets in accordance with scope of practice, organizational policy, and jurisdictional law."@en .
hito:EhrSfmInformationView
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.9.6" ;
hito:subFeatureOf hito:EhrSfmSupportCareCoordinationReporting ;
a hito:FeatureClassified ;
rdfs:comment "Support user-defined information views."@en ;
rdfs:label "Information View"@en ;
skos:altLabel "CPS.9.6 Information View"@en ;
skos:definition "Views of the information can be tailored for or by the user (or department or \"job classification”) for their presentation preferences, within local or facility established rules. For example, a nursing supervisor may elect or prefer to see summary data on all patients as the default view."@en .
hito:EhrSfmInterchangeAgreements
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.5.4" ;
hito:subFeatureOf hito:EhrSfmStandardsbasedInteroperability ;
a hito:FeatureClassified ;
rdfs:comment "Support the use of Interchange Agreements to specify the rules, responsibilities, expectations, and methods by which Interchange Agreement partners may exchange information."@en ;
rdfs:label "Interchange Agreements"@en ;
skos:altLabel "TI.5.4 Interchange Agreements"@en ;
skos:definition "Systems that wish to communicate with each other must agree on certain parameters/criteria that will govern an information exchange process. Interchange agreements enable partnering systems to discover, negotiate, and utilize those parameters/criteria. An EHR-S can use this information to define how data will be exchanged between the sending and the receiving partners. Interchange services and capabilities can be discovered in an automated fashion.Entity directories can be used to determine the address, profile, and data exchange requirements of known, and/or potential Interchange Agreement partners. Entity registries can be used to determine the security, addressing, and reliability requirements between potential Interchange Agreement partnering systems."@en .
hito:EhrSfmInterchangeStandardsVersioningAndMaintenance
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.5.2" ;
hito:subFeatureOf hito:EhrSfmStandardsbasedInteroperability ;
a hito:FeatureClassified ;
rdfs:comment "Support various versions of an interchange standard."@en ;
rdfs:label "Interchange Standards Versioning and Maintenance"@en ;
skos:altLabel "TI.5.2 Interchange Standards Versioning and Maintenance"@en ;
skos:definition "Interchange standards characteristically change throughout their lifecycles; those changes are often tagged with \"version\" numbers. EHR systems need to control the various versions of interchange standards that are used within an EHR implementation and accommodate changes that arise with each version.For example, if an organization migrates to version 2.5 of HL7's messaging standard, it may choose to utilize that version's specimen or blood bank information capabilities. The organization may also find that certain fields have been retained for backwards compatibility only or withdrawn altogether. The EHR-S needs to be able to handle all of these possibilities.Standards typically evolve in such a way as to protect backwards compatibility. On the other hand, sometimes there is little, or no, backwards compatibility when an organization may need to replace an entire standard with a new methodology. An example of this is migrating from HL7 v2 to HL7 v3.Interchange standards that are backward compatible support exchange among senders and receivers who are using different versions. Version control ensures that those sending information in a later version of a standard consider the difference in information content that can be interchanged effectively with receivers, who are capable of processing only earlier versions. That is, senders need to be aware of the information that receivers are unable to capture and adjust their business processes accordingly. Version control enables multiple versions of the same interchange standard to exist and be distinctly recognized over time. Since interchange standards are usually periodically updated, concurrent use of different versions may be required.Large (and/or federated) organizations typically need to use different versions of an interchange standard to meet internal organizational interoperability requirements.For example, the enterprise-wide standard might use HL7 v2.5 for laboratory messages, but some regions of the enterprise might be at a lower level.It should be possible to retire deprecated interchange standards versions when applicable business cycles are completed while maintaining obsolete versions. An example use of this is for possible claims adjustment throughout the claim’s life cycle.When interchange standards change over time, it is important that retrospective analysis and research correlate and note gaps between the different versions’ information structures to support the permanence of concepts over time."@en .
hito:EhrSfmLinkRecordEntries
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "RI.1.1.21" ;
hito:subFeatureOf hito:EhrSfmRecordLifecycle ;
a hito:FeatureClassified ;
rdfs:comment "Link Record Entries (2 or more instances)"@en ;
rdfs:label "Link Record Entries"@en ;
skos:altLabel "RI.1.1.21 Link Record Entries"@en ;
skos:definition "Occurs when Record Entries are linked together. - Entries may be linked for a single an encounter (patient visit)- Entries may be linked for an episode (patient problem)- Entries may be linked for a selected population cohort"@en .
hito:EhrSfmMaintenanceAndVersioningOfStandardTerminologies
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.4.2" ;
hito:subFeatureOf hito:EhrSfmStandardTerminologyAndTerminologyServices ;
a hito:FeatureClassified ;
rdfs:comment "Enable version control according to scope of practice, organizational policy, and/or jurisdictional law to ensure maintenance of utilized standard terminologies.This includes the ability to accommodate changes to terminology sets as the source terminology undergoes its natural update process (new codes, retired codes, redirected codes). Such changes need to be cascaded to clinical content embedded in templates, custom formularies, etc., as determined by existing policy."@en ;
rdfs:label "Maintenance and Versioning of Standard Terminologies"@en ;
skos:altLabel "TI.4.2 Maintenance and Versioning of Standard Terminologies"@en ;
skos:definition "Version control allows for multiple sets or versions of the same terminology to exist and be distinctly recognized over time. Standard terminologies are usually periodically updated, and concurrent use of different versions may be required. Ideally, the meaning of a concept never changes over time, but a concept can be deprecated, and replaced with a new concept in a new version. However, in some terminologies, the meaning of a concept can change over time. In any case, it is important that retrospective analysis and research maintains the ability to relate to the appropriate conceptual meaning. If the terminology encoding for a concept changes over time, it is also important that for legal health records, as well as for retrospective analysis and research, the different encodings can be correlated to ensure the permanence of the concept as originally captured. This does not necessarily imply that complete older versions of the terminology be kept in the EHR-S, only access to the changes needs to be maintained."@en .
hito:EhrSfmMaintenanceCompletedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.10" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track maintenance completed event."@en ;
rdfs:label "Maintenance Completed System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.10 Maintenance Completed System Audit Trigger"@en ;
skos:definition "Capture maintenance completed event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmMaintenanceStartedSystemAuditTrigger
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "TI.2.1.3.9" ;
hito:subFeatureOf hito:EhrSfmSystemAuditTriggers ;
a hito:FeatureClassified ;
rdfs:comment "Manage Audit Trigger initiated to track maintenance started event."@en ;
rdfs:label "Maintenance Started System Audit Trigger"@en ;
skos:altLabel "TI.2.1.3.9 Maintenance Started System Audit Trigger"@en ;
skos:definition "Capture maintenance started event, both routine and exceptional, including key metadata (who, what, when, where, why)."@en .
hito:EhrSfmManageAPatientRecord
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.1.1" ;
hito:subFeatureOf hito:EhrSfmRecordManagement ;
a hito:FeatureClassified ;
rdfs:comment "Manage a single logical record for each patient."@en ;
rdfs:label "Manage a Patient Record"@en ;
skos:altLabel "CPS.1.1 Manage a Patient Record"@en ;
skos:definition "A single record is needed for legal purposes, as well as to organize it unambiguously for the provider. Health information is captured and linked to the patient record. Static data elements as well as data elements that will change over time are maintained. The patient is uniquely identified, after which the record is tied to that patient. Combining information on the same patient, or separating information where it was inadvertently captured for the wrong patient, helps maintain health information for a single patient. In the process of creating a patient record, it is at times advantageous to replicate identical information across multiple records, so that such data does not have to be re-entered. For example, when a parent registers children as new patients, the address, guarantor, and insurance data may be propagated in the children’s records without having to re-enter them."@en .
hito:EhrSfmManageAdministrativeTransactionProcessing
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.9" ;
hito:subFeatureOf hito:EhrSfmAdministrationSupport ;
a hito:FeatureClassified ;
rdfs:comment "Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary foradministrative management during an episode of care."@en ;
rdfs:label "Manage Administrative Transaction Processing"@en ;
skos:altLabel "AS.9 Manage Administrative Transaction Processing"@en ;
skos:definition "Support the creation (including using external data sources, if necessary), electronic interchange, and processing of transactions listed below that may be necessary for administrative management during an episode of care.The EHR system collects patient health-related information needed for purpose of administrative and financial activities including reimbursement.Captures the episode and encounter information to pass to administrative or financial processes (e.g., triggers transmissions of charge transactions as by-product of on-line interaction including order entry, order statusing, result entry, documentation entry, medication administration charting).Automatically retrieves information needed to verify coverage and medical necessity. As a byproduct of care delivery and documentation captures and presents all patient information needed to support coding. Ideally performs coding based on documentation.Clinically automated revenue cycle - examples of reduced denials and error rates in claims.Clinical information needed for billing is available on the date of service.Physician and clinical teams do not perform additional data entry / tasks exclusively to support administrative or financial processes."@en .
hito:EhrSfmManageAdverseEvents
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.1.9" ;
hito:subFeatureOf hito:EhrSfmManageClinicalHistory ;
a hito:FeatureClassified ;
rdfs:comment "Capture and maintain adverse events."@en ;
rdfs:label "Manage Adverse Events"@en ;
skos:altLabel "CP.1.9 Manage Adverse Events"@en ;
skos:definition "This function is focused on the capture and maintenance of adverse events that have occurred to the patient. The system should capture discrete information about the adverse event to enable the rendering Serious Adverse Event (SAE) reports according to organizational policy, and or jurisdictional law. Reporting may conform to the HL7 Individual Case Safety Reporting (ICSR)."@en .
hito:EhrSfmManageAllergyIntoleranceAndAdverseReactionList
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.1.2" ;
hito:subFeatureOf hito:EhrSfmManageClinicalHistory ;
a hito:FeatureClassified ;
rdfs:comment "Manage patient-specific allergy, intolerance and adverse reaction lists."@en ;
rdfs:label "Manage Allergy, Intolerance and Adverse Reaction List"@en ;
skos:altLabel "CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List"@en ;
skos:definition "Allergens to substances, (including immunizations), are identified and the list of allergies is captured and maintained over time. Information regarding allergies may be coded or free text; coded information is preferred (where possible). In this function the term \"allergy\" is used to refer to allergies, intolerances, adverse reactions and sensitivities. All pertinent dates, including patient-reported events, are stored and the description of the patient allergy and adverse reaction is modifiable over time. The entire allergy history, including reaction, for any allergen is viewable. The list(s) includes all reactions including those that are classifiable as a true allergy, intolerance, side effect or other adverse reaction to drug, food or environmental triggers. Notations indicating whether item is patient reported, and/or provider verified are maintained. The term 'true allergy' is defined by the US National Library of Medicine as: an allergy that is caused by a series of chemical steps in the body that produce the allergic reaction. The allergy information that should be captured may vary according to scope of practice, organizational policy, and/or jurisdictional law. For example, the documentation requirements regarding an allergic reaction to a substance that is reportable may require a higher level of data capture."@en .
hito:EhrSfmManageCareCoordinationReporting
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.9" ;
hito:subFeatureOf hito:EhrSfmCareProvision ;
a hito:FeatureClassified ;
rdfs:comment "Provide the functionality required to coordinate care with other providers and report care provided."@en ;
rdfs:label "Manage Care Coordination & Reporting"@en ;
skos:altLabel "CP.9 Manage Care Coordination & Reporting"@en ;
skos:definition "During care provision it is necessary to coordinate care with other providers, internal or external to the organization, as well as to communicate the care provided."@en .
hito:EhrSfmManageClinicalDocumentation
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.3" ;
hito:subFeatureOf hito:EhrSfmCareProvision ;
a hito:FeatureClassified ;
rdfs:comment "Clinical Documentation must be managed including the capture of the documentation during an encounter, maintenance and appropriate rendering."@en ;
rdfs:label "Manage Clinical Documentation"@en ;
skos:altLabel "CP.3 Manage Clinical Documentation"@en ;
skos:definition "Clinical documentation includes all documentation that the clinician may capture during the course of an encounter with the patient or relevant to the patient. This includes assessments, clinical measurements, clinical documents and notes, patient-specific care and treatment plans. Management of clinical documentation also includes the acknowledgement and amendments of documentation provided by other providers."@en .
hito:EhrSfmManageClinicalDocumentsAndNotes
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.3.3" ;
hito:subFeatureOf hito:EhrSfmManageClinicalDocumentation ;
a hito:FeatureClassified ;
rdfs:comment "Create, addend, amend, correct, authenticate, maintain, present and close, as needed, transcribed or directly-entered clinical documentation and notes."@en ;
rdfs:label "Manage Clinical Documents and Notes"@en ;
skos:altLabel "CP.3.3 Manage Clinical Documents and Notes"@en ;
skos:definition "Clinical documents and notes may be unstructured and created in a narrative form, which may be based on a template, graphic, audio, etc. The documents may also be structured documents that result from the capture of coded data. Each of these forms of clinical documentation is important and appropriate for different users and situations. To facilitate the management and documentation on how providers are responding to incoming data on orders and results, there may also be some free text or formal record on the providers’ responsibility, and/or standard choices for disposition, such as Reviewed and Filed, Recall Patient, or Future Follow Up. The system may also provide support for documenting the clinician’s differential diagnosis process."@en .
hito:EhrSfmManageClinicalHistory
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CP.1" ;
hito:subFeatureOf hito:EhrSfmCareProvision ;
a hito:FeatureClassified ;
rdfs:comment "Manage the patient's clinical history lists used to present summary or detailed information on patient health history."@en ;
rdfs:label "Manage Clinical History"@en ;
skos:altLabel "CP.1 Manage Clinical History"@en ;
skos:definition "Patient Clinical History lists are used to present succinct \"snapshots\" of critical health information including patient history; allergy, intolerance and adverse reactions; medications; problems; strengths; immunizations; medical equipment/devices; and patient and family preferences."@en .
hito:EhrSfmManageClinicalWorkflowTasking
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.5" ;
hito:subFeatureOf hito:EhrSfmAdministrationSupport ;
a hito:FeatureClassified ;
rdfs:comment "Create, schedule, update and manage tasks with appropriate timeliness."@en ;
rdfs:label "Manage Clinical Workflow Tasking"@en ;
skos:altLabel "AS.5 Manage Clinical Workflow Tasking"@en ;
skos:definition "Since an electronic health record will replace the paper chart or other paper-based system, tasks that were based on the paper artifact must be effectively managed in the electronic environment. Functions must exist in the EHR-S that support electronically any workflow that previously depended on the existence of a physical artifact (such as the paper chart, a phone message slip) in a paper based system. Tasks differ from other more generic communication among participants in the care process because they are a call to action and target completion of a specific workflow in the context of a patient's health record (including a specific component of the record). Tasks also require disposition (final resolution). The initiator may optionally require a response. For example, in a paper based system, physically placing charts in piles for review creates a physical queue of tasks related to those charts. This queue of tasks (for example, a set of patient phone calls to be returned) must be supported electronically so that the list (of patients to be called) is visible to the appropriate user or role for disposition. The state transition (e.g., created, performed and resolved) may be managed by the user explicitly or automatically based on rules. For example, if a user has a task to signoff on a test result, that task should automatically be marked complete by the EHR when the test result linked to the task is signed in the system. Patients will become more involved in the care process by receiving tasks related to their care."@en .
hito:EhrSfmManageCommunication
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.4" ;
hito:subFeatureOf hito:EhrSfmAdministrationSupport ;
a hito:FeatureClassified ;
rdfs:comment "Support communication to enable the exchange of information internally and between healthcare and non-healthcare organizations."@en ;
rdfs:label "Manage Communication"@en ;
skos:altLabel "AS.4 Manage Communication"@en ;
skos:definition "Communication among providers involved in the care process can range from real time communication (e.g., communication between a therapist and nurse), to asynchronous communication (e.g., consult reports between physicians). Some forms of inter-practitioner communication will be paper based and the EHR-S must be able to produce appropriate documents.The system should provide for both verbal and written communication. These exchanges would include but not be limited to consults, and referrals as well as possible exchanges within the office as part of the provision and administration of patient care (e.g., the communication of new information obtained within the office environment during the process of administration of a tetanus shot while the patient is in the exam room)."@en .
hito:EhrSfmManageConsentsAndAuthoizationsFromAPhr
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "AS.3.2.1" ;
hito:subFeatureOf hito:EhrSfmManagePersonalHealthRecordInteraction ;
a hito:FeatureClassified ;
rdfs:comment "Maintain the Consents and Authorization directives/statements from the patient's PHR."@en ;
rdfs:label "Manage Consents and Authoizations from a PHR"@en ;
skos:altLabel "AS.3.2.1 Manage Consents and Authoizations from a PHR"@en ;
skos:definition "Provide the ability to manage Consents and Authorizations from a Personal Health Record including manage access control for individual elements of records to which the Consent or Authorization applies"@en .
hito:EhrSfmManageConsentsAndAuthorizations
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;
hito:internalId "CPS.1.7.3" ;
hito:subFeatureOf hito:EhrSfmSubjectToSubjectRelationship ;
a hito:FeatureClassified ;
rdfs:comment "Create, maintain, and verify patient decisions (such as informed consent for treatment or disclosure)."@en ;
rdfs:label "Manage Consents and Authorizations"@en ;
skos:altLabel "CPS.1.7.3 Manage Consents and Authorizations"@en ;
skos:definition "Decisions are documented and include the extent of information, verification levels and exposition of treatment options. This documentation helps ensure that decisions made at the discretion of the patient, family, or other responsible party, govern the actual care that is delivered or withheld. There may be several documents active at any one time that may govern a patient’s care. Both Clinical and administrative consents and authorizations are considered part of this function. A consent or authorization includes patient authorization for re-disclosure of sensitive information to third parties. Consents/Authorizations for printing should include appropriate standardized forms for patients, guardians, or foster parents. The system must appropriately present forms for adolescents according to privacy rules.Some jurisdictions may mandate assent. Assent is agreement by the patient to participate in services when they are legally unable to consent (e.g., an adolescent, an adult with early dementia)."@en .
hito:EhrSfmManageConsultationRequestsAndResponses
hito:featureCatalogue hito:EhrSfmFeatureCatalogue ;